Re: The attribute key cannot be found (a new twist in the story)
- From: Chris Webb <onlyforpostingtonewsgroups@xxxxxxxxxxxxxxx>
- Date: Mon, 30 Oct 2006 07:08:02 -0800
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?
- References:
- Prev by Date: Calculation based on previous member HELP
- Next by Date: count date dimention
- Previous by thread: Re: The attribute key cannot be found (a new twist in the story)
- Next by thread: Re: Time Dimensions
- Index(es):
Relevant Pages
|
