November 30, 2006 at 7:21 pm
Hi,
I am trying to process a cube, but getting the error below:
Errors in the OLAP storage engine: The attribute key cannot be found: Table: dbo_myfact, Column: DealerGroupID, Value: 0. Errors in the OLAP storage engine: The attribute key was converted to an unknown member because the attribute key was not found. Attribute Dealer Group ID of Dimension: Dealer Group Grouping from Database: DatamartTest, Cube: MyCube, Measure Group: My Fact, Partition: myfact, Record: 1713454.
I checked the fact table and the dimension table and found that there was no "0" value in the dimension table. After I inserted the value, the error did not go away. The list of current values in both tables is below.
What could be the problem.
Thanks.
Fact table | Dim table |
0 | 0 |
3 | 3 |
5 | 5 |
8 | 8 |
10 | 10 |
15 | 15 |
17 | 17 |
18 | 18 |
21 | 21 |
23 | 23 |
24 | 24 |
47 | 47 |
51 | 49 |
52 | 50 |
53 | 51 |
54 | 52 |
57 | 53 |
58 | 54 |
59 | 57 |
60 | 58 |
61 | 59 |
62 | 60 |
63 | 61 |
64 | 62 |
66 | 63 |
67 | 64 |
66 | |
67 |
November 30, 2006 at 9:58 pm
Just out of interest, did you do a 'Process Update' on your dimension before doing the cube process? If so, did you open/browse the dimension (not from within the cube itself but standalone) and check that the member does exist?
Cheers,
Steve.
March 4, 2008 at 3:21 pm
I have had a similar problem. I processed a cube, received a key not found error, added the missing key to the dimension table, and received the same error when trying to reprocess the cube. SSAS must have some old metadata stuck in its craw because if I create a new SSAS database and set it up exactly like the first one, the cube processes without a problem.
Does anyone know how to refresh or cleanse SSAS? I can't keep on rebuilding duplicate copies of cubes every time I get a processing error.
March 5, 2008 at 6:10 am
Assuming MOLAP all the way, you need to process the dimension to have it pick up changes in the underlying dimension table. Then you should be able to process the cube successfully.
March 6, 2008 at 8:10 am
Some general comments around these concepts:
- While you're in the design and testing stages, get in the habit of doing full process only. It'll make things simpler. The process update works and is solid, but the rules behind it may not be obvious at first glance if you're new to MSAS. Once you've understood the dependencies (of MSAS and your model), things get much simpler.
- When connecting attributes to the dimension table (leaf level attribute) I recommend you use the foreign key on the dimension table as the id and the description from the attribute table. (As opposed setting the id as the key field on the attribute table.) It has to do with the way MSAS forms queries, null values, etc.
- Expect to implement RI checks on your database model (the data), even if you trust the data coming in. In this example, the missing dim table record shouldn't have occurred. (Create a Dim record with ID = 0 , description = 0, etc.) You can set MSAS to skip errors, but I wouldn't recommend it. It could hide other problems you do want to fix.
- Regarding the comment on MSAS having some "old meta stuck" (I think bwilliams meant data actually). I think find MSAS actually pretty robust in this area. In general, it's simply a matter of "user error" (ouch!!). To empty a cube, do an unprocess on the "database".
Note: with MSAS 2005, the architecture changed. For those people who are just starting out, process, unprocess, etc. at the "MSAS database level". Dimensions and cubes are children of the database. You'll save yourself much grief. When you need to get into incremental updates, I think you find it works quite logically, once your cube design is stabilized.
March 17, 2008 at 9:11 am
The suggestion to process the dimension first and then the entire cube has solved my problem. I have had success doing it this way for a couple of weeks now. Thanks!
July 17, 2008 at 7:14 am
I've had this problem for some time against a VLDB, and I'm not getting anywhere. I can browse the dimensions in question and see the members the cube engine says are missing. The only way to get rid of it is to set processing option to convert to unknown, so now I question the aggregations. Has all the indications of a bug and/or caching problem.
September 25, 2008 at 9:15 am
Hi,
I'm currently seeing a similar error but it's being caused by NULL dimension keys on the fact record being converted to 0 when the cube is processed.
I have the dimension set up to use the Unknown Member and the NullProcessing option on the key attribute set to UnknownMember but I still get the same error.
If I update the fact table to use a -1 key where it is currently NULL (and use an explicit dimension member of -1,Unknown) everything is fine. However, if I set the dimension key back to NULL on the fact rows and attempt to use the Unknown Member I get the error.
I'm guessing there might be some further configuration I need to do to make the Unknown Member work.
Any suggestions?
Thanks.
May 19, 2009 at 1:16 am
Hi
I know this post is Old.. but I'm facing the same problem and not able to figure out what is wrong!!
I have migrated SSAS from 2000 to SSAS 2005. When i process one of my cube it passes me error:
"Errors in the OLAP storage engine: The attribute key cannot be found: Table:
May 19, 2009 at 1:54 am
it turned out the answer to my problem was configuring the NULL processing in the dimension usage panel in the cube. i had configured the dimension to use an Unknown member for NULLs but hadn't configured the dimension usage in the cube.
doh!
May 19, 2009 at 1:56 am
it turned out the answer to my problem was configuring the NULL processing in the dimension usage panel in the cube. i had configured the dimension to use an Unknown member for NULLs but hadn't configured the dimension usage in the cube.
doh!
July 28, 2009 at 4:48 am
Check if the fact table have null values for sk's which are not present in dimensions, if exists then fix the null values for sk's and the cube be processed
Regards,
Sandesh Segu
http://www.SansSQL.com
February 5, 2010 at 8:55 am
I'm having a similar issue.
I added 1 record to my dimProductLine dimension table.
I process the dimension, but the new record does not appear in the list of members.
So I look in the DSV, and I can explore my dimProductLine table and see the record in question is definately there, so, I have no clue why processing this dimension does not pull this 1 record or member into the SSAS dimension.
Any thoughts? Else I'll just add this one to my list of Microsoft Bugs.
Thanks
February 5, 2010 at 9:30 am
I don't think a bug is causing this. It might be one of:
1. Whatever you're using to browse the dimension is looking at an old copy. Try hitting a reconnect or refresh button. Try closing and reopening the tool.
2. You may be browsing the cube rather than the dimension, and there might not be any facts for the new member. Go to SQL Server Management Studio, expand the OLAP DB, expand dimensions, right-click your dimension and click browse.
3. The dimension may not have processed completely. Try a "process full".
If all else fails, and you just want to get it to work, process the whole OLAP DB with "process full", close and reopen your client tool.
February 5, 2010 at 9:54 am
Successs. Here's the deal:
1. Refresh and reconnect did not work for me, nor did opening and closing BIDS.
2. When I processed the dimensionn from Management Studio, then things worked. I clicked refresh in BIDS, and finally the new member was in my dimension.
3. A Process Full from within BIDS would not work, even though it said it processed. Tried reconnecting and refreshing...nothing changed.
When I processed the cube from Management Studio, then I finally got my updated fact data with with new member as well.
Thanks for the help, at least I can get it to work. However, its very concerning that this no longer processes within BIDS. I checked the data source, cube and where the project is set to deploy to. Everything looks correct. And this did work from BIDS when I had to deploy it initially. Maybe something is messed of up my SSAS project. That's 4 hours I'll never get back.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply