Re: Error processing cube with disabled lowest level of shared dimension
- From: "Ohjoo Kwon" <ojkwon@xxxxxxxxxx>
- Date: Fri, 8 Apr 2005 02:39:12 +0900
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@xxxxxxxxx> wrote in message
news:1112867147.829870.262010@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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
>
.
- Follow-Ups:
- References:
- Prev by Date: Cube failed to load
- Next by Date: MSSQLServerOLAPService terminated unexpectedly
- Previous by thread: Re: Error processing cube with disabled lowest level of shared dimension
- Next by thread: Re: Error processing cube with disabled lowest level of shared dimension
- Index(es):
Relevant Pages
|
Loading
