I am new to SSAS and am setting up a proof of concept. I love the idea of Role-Playing dimensions, but i'm having trouble getting one setup that is NOT based on dates. Here is the use-case:
In our ERP system, we have a fact table we'll call "Time Entries" that has:
User_ID
Biller_ID
Approver_ID
Hours Worked
ETC
I also have a "Resource" table that i'm relating these to as foreign keys:
Resource_ID
Department_Name
ETC
When I create my Data Source View, I create a relationship between:
User_ID -> Resource_ID
Biller_ID -> Resource_ID
Approver_ID -> Resource_ID
My "Resource" Dimension can be successfully deployed and processed, and has the following Attributes:
Resource_ID
Department Name
My "Work Entries" cube has one measure, "Hours Worked". When I add in my "Resources" dimension, it creates three roleplaying dimensions:
User
Approver Resource
Biller Resource
When I go to process, i'm receiving the following error:
Errors in the OLAP Storage Engine: The attribute key cannot be found when processing: Table: 'Time Entries', Column: 'user_id', Value: 'some number', The Attribute is 'Resource ID'.
So far, the only post I've followed that allowed me to successfully troubleshoot is this one:
https://www.sqlservercentral.com/Forums/1219713/Errors-in-the-OLAP-storage-engine-The-attribute-key-cannot-be-found-when-processing-Even-though-key-Exist-in-Dim-Table
TL;DR -
I've delete the relations between the factable and dim tables in the database.
I refresh the dataSourceViews and thera are no relations between tables
I remove the dimentions in the cube design
I recreate the dimentions in the cube design
I build then relations in the dataSourceViews between the foreign key in the factable and the primary keys in dim tables
i reprocesed the cube
The problem with this is that because we've added the dimension back BEFORE creating the relationships, we don't have our roleplaying dimensions.
I feel like i'm missing something simple here, but I can't quite figure it out. Can anyone tell me why my roleplaying dimensions aren't working?
Roleplaying function of a dimension does not depend on its type. Your dimensions can be used in role-playing scenario like Date dimension.
On your problem - SSAS engine might build sometimes strange queries extracting dimension data, especially when your dimension is based on data from several tables. To check and investigate it:
Fix user_id value from your error message
Do process update or process full on corresponding dimension, and get SQL query used for processing user_id attribute from processing window form. It is under processing user_id attribute log entry.
Copy SQL query and run it. Check whether it returns id from the error message above.
If the value is missing - investigate the query
In my experience - such things occurred when an erroneous dimension was built on two tables with some relation. SSAS engine have built query with strict inner join, and it has to be less restrictive left outer join.
You can fix it with SSDT playing with DSV attribute being non-empty, but I found more simple to write a SQL query with proper joins in DSV directly.
Related
I have the need to create a simple cube from a single table (view), no dimensions and facts star schema type stuff..
I have a large flat table (100+ columns). This table is a straight import from a CSV file, so I then create a view that includes a ID column...
As an example...
CREATE VIEW [dbo].[v_dw]
AS
SELECT
newId() Id,
x.[customer]
FROM dwdump as x;
GO
In SSAS designer I create my DSV from the view and all the int columns end up as fact data and all the varchar columns end up in a single dimension.
I try to process this cube and it throws duplicate record exist, so I set it to ignore this error, then it throws
The attribute key cannot be found when processing
The full error is...
Errors in the OLAP storage engine: The attribute key cannot be found when processing: Table: '[dbo].[v_dw]', Column: 'Id', Value: '{D0B94A2D-7024-4634-844F-64768ED4B203}'. The attribute is 'Id'. Errors in the OLAP storage engine: The record was skipped because the attribute key was not found.
I know that building a cube without proper fact/dimensions defined in the table is against best practices, but I need something simple and quick.
Can we not create a cube from a single table and use a arbitrary [Id] key column.
This can be the result of measures being processed before dimensions, leading the corresponding key not found in the dimension. As you indicated in your comment, processing the dimensions doesn't pose any problems. Since this post is tagged with SSIS I'm assuming that you're either using an Analysis Services Processing task or processing via commands such as XMLA. When you define how the cube is processed set the dimensions to process before the fact table containing the measures is processed.
First Process Update the concerned dimension. After this is done, PROCESS FULL the concerned measure group individually. Faced this issue several times, and this fix always works.
One of our production cube failed with the following error message:
Source: Analysis Services Execute DDL Task Analysis Services Execute
DDL Task Description: Errors in the OLAP storage engine: The
attribute key cannot be found when processing: Table:
'dbo_vw_FACT_OperationalTimeSheetData', Column: 'CurrentHomeLaborOrg',
Value: '117-MARKETPLACE-38'. The attribute is 'KeyOrganisation'. End
Warning Warning: 2013-07-22 06:26:07.51 Code: 0x811F0002
Source: Analysis Services Execute DDL Task Analysis Services Execute
DDL Task Description: Errors in the OLAP storage engine: The
attribute key was converted to an unknown member because the attribute
key was not found. Attribute KeyOrganisation of Dimension: Current
Home Organisation from Database: LadbrokesReporting2005, Cube: MIS
Clone, Measure Group: Kronos Time Sheet, Partition: 201307, Record:
179774. End Warning
On extensive google searches for the above error message I learnt this is due to referential integrity i.e some rows in the fact table could not be linked to the dimension table. In my previous analysis I figured that the for some of the values like the one given above in the error message '117-MARKETPLACE-38' in the fact table , the format in the dimension table was '117_Marketplace_38'. However, I have unearthed some striking facts :-
The query for the view which populates the fact converts data inthe the format '117-MARKETPLACE-38'. The format of the data in the source tables is '117_Marketplace_38'.
There are many other entries of the format '117-Marketplace-38'. However, the error seems to be present only for that entry. So how come others are getting accepted but this isnt?
I've run out of ideas. Hence, it would be great if someone could help me out on this.
Are you sure that the dimension is processed? Remember that as it links the facts to the dimensions, it does so on the SSAS dimension, not the underlying SQL table. Try running a process(Update) on the dimension first?
In your original post you're mixing upper and lower case, MARKETPLACE and Marketplace. Is this how it is in the source? It could be that it isn't treating them as the same. I've seen SSAS have issues with "Id" versus "ID"
Possible relative of ssas attribute key cannot be found even though it exists and is not due to duplicates
Edited comments into answer after acceptance.
I got this same error message, but had to handle it differently in my case: details below for others who run into the same issue.
In my scenario, I was connecting my fact table to another fact table via a bridge table. This bridge table was formed via an INNER JOIN, so it only had records that matched in both; legitimately, then certain rows in FactTableA were not in the BrgTable joining to FactTableB.
To allow FactTableA to process even when there were no valid links to BrgTable, I followed these instructions from TechNet:
Referential Integrity Issues in Fact Table
The sales fact table has records with product_id that does not exist
in the product dimension table. The server will produce a KeyNotFound
error during partition processing. By default, KeyNotFound errors are
logged and counted towards the key error limit, which is zero by
default. Hence the processing will fail upon the first error.
The solution is to modify the ErrorConfiguration on the measure group
or partition. Following are two alternatives:
Set KeyNotFound=IgnoreError.
Set KeyErrorLimit to a sufficiently large number.
The default handling of KeyNotFound errors is to allocate the fact
record to the unknown member. Another alternative is to set
KeyErrorAction=DiscardRecord, to discard the fact table record
altogether.
For me, I had to go to the partition associated with the failing measure group, open up the Properties pane, set ErrorConfiguration to Custom, and then expand Custom and set KeyNotFound to IgnoreError.
In my searching, I have seen this error text been asked in different contexts, but specifically, I want to know if I am missing something here.
In a basic setup, I have 1 measure table and 1 dimension table in my DSV. In my test, the measure table has about half of the sold products, but the dimension table has info on the entire product catalog.
The relationship has the measure table as the foreign key and the dimension as the primary. Case is not an issue as both are integers.
What am I doing wrong? I have tried reversing the relationship and I always process the dimension in full before processing the cube in full whenever I make a change.
To avoid the errors, I can set the ignore key errors thing or ensure that the dimension only contains the products that the measure contains. I can do the latter, but I feel that using an unfiltered reference table is cleaner and more efficient - it's on that note that I say "am I missing something?"
Apologies for wasting everyone's time on this one. I was going to delete the question but thought I would share my self-rectified findings:
In my above example, I failed to mention that the dimension table also had links to other tables. Missing (null) references between those tables caused the dimension member to be missing when processed hence the 'attribute key could not be found' when the cube was processed!
In SSAS I have three dimensions one of which relates to a fact table. When I process the dimension with attributes from each of the other two dimensions I get the above error.
There is definitely a join, between the main dimension and the other two dimensions. The primary key in the same dimension i.e book also relates to the other book foreign keys in the other dimensions.
If I script with two joins it works but SSAS doesn't seem to pick this up.
I have looked at previous posts and tried their recomendation but they are not appropriate for my issue it seems.
Have you refreshed your DSV ? From what i can remember this was usually caused by something going mishap in the DSV, so that the table or view used for the dimension wasn't accessible
Could you post your DSV? Last time I saw this error message, the table relationships were set up incorrectly in the DSV, causing a circular reference.
This error occurs due to selection of attribute from any other tabale/view instead of related one.
Go to dimension structure -> datasource view pane (center pane)
Right click and -> show related tables
Drag and drop field from table/view .
It should work fine.
Why is it not necessary to define a hierarchy using the Date attribute from a date/time table?
The Analysis Service project seems to want me to create a hierarchy within my Dimension -- the tooltip says "Create hierarchies in non-parent child dimensions". I really had none that came to mind, so I tried adding a the PK Date attribute from my Time table, and creating a hierarchy with that.
When I do this, I get the error "Errors in the high-level relational engine. The 'dbo_Orders' table that is required for a join cannot be reached based on the relationships in the data source view."
I noticed in the AdventureWorks sample never uses Date in a hierarchy. Why is this?