Hi,

This is probably a classic scenario with a shared dimension that we
need to use in different cubes, where all fact tables do not offer the
same level of detail. Dimension is snow-flaked.

The cube that's causing me troubles was designed by marking the lowest
dimension level Diabled and not Visible. This allows me to get rid of
one of the snow-flake tables (the one with the lowest level), thus
allowing an INNER JOIN with the remaining table which has a level of
detail corresponding to the fact table.

When processing the cube, I get a 'member with key '[blah]' was found
in the fact table but was not found in the level '[blah]' of the
dimension '[blah]'' that seems to indicate that none of my fact foreign
keys exist as primary keys in the dimension table. However if I then
attempt to query the cube, all data seems to be there.

Would anybody be in a position (and willing ;-)) to share his/her own
experience working around a similar issue? Do the error messages even
matter in that particular case?

Thanks,

SRL

I use the same technique you describe quite often, however, I've never
come across the error message you described if the error condition
wasn't really there.


SRL wrote:

If new dimension records and fact records are added but the dimension is not
updated, the kind of error can occur during cube processing.

Although the dimension is updated, if schema optimization is applied and
there are some inconsistency between dimension and fact tables, the error
can also occur.

Ohjoo Kwon


"SRL" <srlanger (AT) gmail (DOT) com> wrote

Thank you both for your input. At least I know I'm almost doing things
right ;-) I removed cube optimization, reprocessed dimensions, then the
cube, but still get the error messages - and still a correct aggregated
result.

I'll keep investigating. Will probably build a new test cube from
scratch. Any additional input is stull highly welcome...

Thanks,

SR