Errors in the high-level relational engine

I'm getting an error when processing a partition - Errors in the high-level relational engine. The table_name table that is required for a join cannot be reached based on the relationships in the data source view.

This table is actually joined to another dimension table, which is then joined to the fact table.

How can I resolve this error?

I did notice that there are no keys in the dimension table that relate to the fact table for this particular table. Is this a data issue?|||Well, that might be the reason... To be honest I can't imagine a business case where you have a dimension table without any link to a fact table... Perhaps you can help me to understand you issue...|||

Usually I find that missing dimension key issue when there is corruption in the data. My underlying view was actually pointed to the wrong database - I corrected that but surprisingly it still didn't fix the problem.

Interestingly enough, the previous AS 2000 database used the 'name' column as a key for some of the dimensions. In AS 2000 this was acceptable as long as they were unique. AS 2005 doesn't like that so much. So I went through each dimension & changed it's key column to the proper key.

I am still troubleshooting for some other dimensions. I think it has something to do with the datatype being bigint instead of double in a dimension key. I am finding this to be a very tedious and time-consuming process.

If there's any way of visuallizing the two queries side-by-side to compare dimension/fact table keys that may help me.

Also, are there any resources on how to best hook up a dimension that has a related dimension but no fact table key. (eg Dimension Group links to Dimension links to Fact)?

|||

Andrew,

you can define a snowflake schema (Dimension Group links to Dimension links to Fact). You simply define more than one table in your dimension...

I think SSAS 2005 is more restrictive when it comes to keys. And yes, I think it's good. It takes some time to get used to it but a good design helps you much in this case... And having a name as a key is everything but best practice...

Having a double as a key is also not best practice... It's much better to have int/bigint at this point...

You can also switch on the build-in "unknown member" support... It's much better to do that on your own in the ETL process but i.e. if you set your cube directly on top of a productive system it might be helpful...

|||

Good tips. thanks! I am just trying to get it processing successfully, so the double/bigint switch will be something to try afterwards. The dimension/fact table key data should line up and there is a big problem when every record has unknown dimension members.

Let's hope that processing 21m rows in the dimension today is faster than yesterday.