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!
Related
I'm working on a data warehouse project using BigQuery. We're loading daily files exported from various mainframe systems. Most tables have unique keys which we can use to create the type 2 history, but some tables, e.g. a ledger/positions table, can have duplicate rows. These files contain the full data extract from the source system every day.
We're currently able to maintain a type 2 history for most tables without knowing the primary keys, as long as all rows in a load are unique, but we have a challenge with tables where this is not the case.
One person on the project has suggested that the way to handle it is to "compare duplicates", meaning that if the DWH table has 5 identical rows and the staging tables has 6 identical rows, then we just insert one more, and if it is the other way around, we just close one of the records in the DWH table (by setting the end date to now). This could be implemented by adding and extra "sub row" key to the dataset like this:
Row_number() over(partition by “all data columns” order by SystemTime) as data_row_nr
I've tried to find out if this is good practice or not, but without any luck. Something about it just seems wrong to me, and I can't see what unforeseen consequences can arise from doing it like this.
Can anybody tell me what the best way to go is when dealing with full loads of ledger data on a daily basis, for which we want to maintain some kind of history in the DWH?
No, I do not think this would be a good idea to introduce an artificial primary key based on all columns plus the index of the duplicated row.
You will solve the technical problem, but I doubt there will be some business value.
First of all you should distinct – the tables you get with primary key are dimensions and you can recognise changes and build history.
But the table without PK are most probably fact tables (i.e. transaction records) that are typically not full loaded but loaded based on some DELTA criterion.
Anyway you will never be able to recognise an update in those records, only possible change is insert (deletes are typically not relevant as data warehouse keeps longer history that the source system).
So my todo list
Check if the dup are intended or illegal
Try to find a delta criterion to load the fact tables
If everything fails, make the primary key of all columns with a single attribute of the number of duplicates and build the history.
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.
We are having a very frustrating problem with SSAS. we are trying to create a fairly simple Tabular model have had no problem with a few dimensions and a single fact table. when we recently added a new dimension table, and a second fact table we can not get it to stop telling us that
The relationship cannot be created because each column contains duplicate values.
we have deleted and reimported these tables many times. at times we can attach the Dim table to an existing fact without problem, which tells me that the key is unique, but then it errors when attaching to a second fact. at other times it just errors right away.
The key and Foreign Key values are Int in the database. and we have examined the data many times, creating stripped down tables with just a few columns, validating that a
Select Distinct ID from Table
type query returns the same number of rows as a wide open one.
At this point it looks like we simply have a bug in SSAS Tab. I cant see a good reason for this to not work.
any ideas would be greatly appreciated
I have had the same problem, the way I solved is to create the relationship in reverse order meaning: from the 1 to many. This will solve the issue, and the relationship's direction will indeed be from the many to the 1
I do not have any explanation for this...
sometimes SSAS cannot detect that your column is unique so you should do that. you can click on your primary key column and get properties and choose true on the unique property and after that create your relationship
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 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.