I have a cube with 8 dimensions and very large facts (hundreds of trillion as
BigInt).

The summation of thes numbers in Analysis does not match the sumation of the
numbers when running a simple Sum(Column) query against the factTable. We
are talking an error of 0.09%.

I have tested various data types and the error still exists.

Is this expected behavior or what??
--
Thanks in advance
GH

Hello,

Are you using SQL server 2000 Analysis services? I have tested but didn't
find similar issue.

To troubleshoot the issue, please post here the detailed steps to reproduce
the issue on the sample database FoodMart 2000. I will check it on my side.

I look forward to hearing from you.

Sophie Guo
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security

================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

HI Sophie,

I am using AS on SS2k.

I have not had this problem in the past either

The FoodMart expense_fact has 2400 rows ..

The difference is the fact table I am currently using has 56 million rows
and the totals I am dealing with are:

a.) Querying the fact table gives me a sum of 682,527,391,982,143
b.) The Cube gives me a sum of 682,522,349,614,812

The data type in the fact table and the cube is BIGINT.

When reviewing the data in the cube I have all the dimensions set to 'All
-----'

Thanks
GH


"Sophie Guo [MSFT]" wrote:

GH -

No, this should not happen. Two things I believe could have caused this to
happen, and you've already ruled out one of them, the data type. Mismatching
datatypes between the SQL column and the OLAP measure could do this, as could
an OLAP datatype not appropriate for the measure (int instead of decimal or
currency, etc) but you've already confirmed they're both BigInts.

Therefore, the next thing to check would be if any fact rows didn't make it
into the cube. Since you're SQL value is higher than the cube value, this
would be my guess. I don't know what kind of integrity you have between your
dims and your fact table(s), but it's possible that some rows didn't have
matching parents, and therefore the query used at cube-build time dropped
those rows.

To test, you can re-process the cube and check the count of rows processed.
If it doesn't match the count of the rows in the fact table, you've found the
culprit.

Good luck.

- Phil

"GH" wrote:

Good suggestions ..

I ended up creating new cubes starting with one dimension and adding one at
a time until the summation error surfaced.

Found a dimension that was created from a view. It had a WHERE clause that
should not have existed.

The terra numbers now match!!

Thanks
--
Thanks in advance
GH


"SQL McOLAP" wrote: