You are not logged in.

Dear visitor, welcome to Palo Community Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

marc237

Master

  • "marc237" is male
  • "marc237" started this thread

Posts: 33

Date of registration: Oct 27th 2009

Occupation: Student

  • Send private message

1

Monday, November 9th 2009, 4:40pm

Weird table-Data, even with example

Hi,

I just started to look at JPalo and noticed that the JTable produced by the example-Code "JTableDemo" produces results that don't match those of the PaloClient and Excel. The Client and Ecxel show a total of 45.367.531,86 while the API-Demo displys 5191,0 and even goes into the red at Germany's total with -3732,0 and numerous other places. Am I the only one experiencing this?

I should also point out that I skipped the special start-thing in the readme concerning the two dll-Files (palojava.dll ,libpalo.dll) based on this thread http://www.jedox.com/community/palo-foru…d=4873#post4873 ,which said they were just used for legacy-purposes.

Thanks for your help
Marc

philipp

Professional

Posts: 31

Date of registration: Jul 16th 2007

Location: Düren, Germany

Occupation: Software Developer

  • Send private message

2

Thursday, November 12th 2009, 12:01pm

RE: Weird table-Data, even with example

Hi,

that's because the JTableDemo uses different values for the "fixed" dimensions (i.e. those that are not visible in the table). While JPalo and the Excel client both select the "All"-Element of the remaining dimensions, JTableDemo uses the element with the id 0, which in most cases is not the "All"-Element. For example, in the "Months"-Dimension, the 0 Element is "Jan" -- not "Year".

You can get the same data as in JPalo or in the Excel client by setting the all element, which can be done by setting the element like this:

dimension.getDefaultHierarchy().getRootElements()[0];

(Although it is wise to test for the existance of a root element prior to accessing it like this :)).

Hope that helps,
kind regards,
Philipp

marc237

Master

  • "marc237" is male
  • "marc237" started this thread

Posts: 33

Date of registration: Oct 27th 2009

Occupation: Student

  • Send private message

3

Thursday, November 12th 2009, 1:31pm

Brilliant!

Thanks, that was it! I discarded the idea of some sort of weird dicing of the cube because I assumed that ElementAt(0) would supply me with the Root-Element, and never verified that assumption! I feel rather silly now! :]

marc237

Master

  • "marc237" is male
  • "marc237" started this thread

Posts: 33

Date of registration: Oct 27th 2009

Occupation: Student

  • Send private message

4

Thursday, November 12th 2009, 3:02pm

Sadly, I was rather optimistic before!

I still get the same weird results. I just noticed, that I never mentioned that the first line is always correct, the rest however isn't.

When I artificially increase the returned dimension, the wanted results are contained somewhere in the resulting Array. maybe I am doing something wrong with the coordinates[]?
My concept has always been to put the dimensions that I wanted to display in the first two Elements of the array and then followed by all the other dimensions of the cube. Is that appropriate?

Thanks a lot for the help!!
Marc

marc237

Master

  • "marc237" is male
  • "marc237" started this thread

Posts: 33

Date of registration: Oct 27th 2009

Occupation: Student

  • Send private message

5

Friday, November 13th 2009, 9:07pm

I think I cracked it (again...)!

Apparently, the coordinates[] need to be passed according to their getDimensionAt() position, not their row/column-position in the resultint table! Does that sound right this time??

Rate this thread