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?

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 (AT) discussions (DOT) microsoft.com> wrote

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:

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 (AT) discussions (DOT) microsoft.com> 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:

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: