Re: The attribute key cannot be found (a new twist in the story)
- From: Ashok <Ashok@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 28 Dec 2006 11:56:02 -0800
Here is another story and NeilW unless I don't get better control of 2005 I
do believe that little magic.
I also got this error and this is what I think and know...
In AS2000 we have only one place in cube to fix data integrity issues. That
is in cubes properties set "Stop Processing on Key Errors" = "No"
In AS2005 there are more then one place at least worth trying which one
works for you. There are three places Cube, Measure Group and Partitions you
get "ErrorConfiguration" - (custom) set all the places "KeyErrorLimit" =
"-1". This think Measure Group would be best place to start.
There are other solutions at design time like using s key -1 but if you are
getting this error it's too late.. set the properties.
-Ashok
"Chris Webb" wrote:
Not sure whether this fits your scenario, but I've seen this error message on.
case sensitive installations. If I remember correctly, it was happening when
I was using a char or varchar column as the key of an attribute and there
were rows where the values were the same but the case was different, eg in
the City column there might be values like 'LONDON' and 'London'. Forcing
everything to the same case cured the problem.
Chris
--
Chris Webb, MVP
Analysis Services and MDX Consultancy: http://www.crossjoin.co.uk
Blog: http://cwebbbi.spaces.live.com/
"NeilW" wrote:
Thanks for your response. I will certainly use your practice in future
implementations.
I have actually solved my problem by deleting the dimension and creating it
again. Like magic, the attribute keys were suddenly found. I have noticed
this problem before on a couple of third party training courses. Dare I call
this a BUG?!?!
"Ohjoo Kwon" wrote:
If the dimension processing is done first, I usually like to run next kind
of query for simple verification.
SELECT Top 10 A.DimId, ...
FROM FactTable A LEFT OUTER JOIN DimTable B
ON A.DimId = B.DimId
WHERE B.DimID IS NULL
If some records are returned, it will cause key errors during cube
processing in AS 2005.
But it does not cause key errors in AS 2000 until schema optimization,
because the joins between dimension and fact tables are alive during cube
processing.
Ohjoo
"NeilW" <NeilW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CA306376-C7B7-4704-8C1B-449C3FE8ABAA@xxxxxxxxxxxxxxxx
Thanks for the response. My Integration Services package does process the
dimensions before the cubes but I will certainly run a trace.
I should have mentioned that 95% of the records in the dimension and fact
tables have actually been matched. It is just 5% of the records that do
not
match, even though all the key attributes that I have investigated appear
to
match. However, the fact table consists of 32 million records so there is
still an enormous 1.7m records where the key attribute "cannot be found".
"Jesse O." wrote:
My first suggestion would be: make sure the dimension is processed before
the partition. :)
As a first step, I'd run a trace (if you're using SQL Server RDBMS) to
capture the SQL being sent in by AS. Run that and see if anything is off.
Are the datatypes set the same in AS?
"NeilW" <NeilW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:06D53631-A40F-451B-B48C-C4A747828436@xxxxxxxxxxxxxxxx
I have searched everywhere for an answer to this particular problem. As
many
others have found, the message "The attribute key cannot be found"
occurs
when (typically) a key attribute in a fact table cannot be matched in a
dimension table. I have implemented the appropriate steps in the
"Custom"
option of "Error Configuration" in properties to handle such problems.
I
have, however, found a situation in a cube where, despite appropriate
keys
existing in the dimension table/s for transactions in the fact table,
some
of
the records are being treated as "Unknown". Not only do the keys exist
in
both the dimension and the fact tables but the data types for the
matching
columns are the same.
The only unusual point that I can think of is that the relational
staging
database has been created in SQL Server 2000 while the cube has been
created
in SQL Server 2005.
Is there anything I have missed that could solve this problem?
- Prev by Date: Re: Performance problem
- Next by Date: Re: Update Cube MDX executes but no rows added to writeback table
- Previous by thread: RE: The attribute key cannot be found
- Next by thread: Formatting MDX % Problem I looked everywhere about could not find any solution
- Index(es):
Relevant Pages
|
