Today I came across a strange issue in SSAS. I am building a cube that has a fact dimension, which is built using two different tables.

The table used to build the dimension (which is a customer dimension by definition) has to be used as a fact table as well because it stores certain customer specific  information that can be used in conjunction with other measures to perform certain calculations.

One of the attributes in the dimension though needs to be referenced from another table that resides in a different database.

It all works fine during the design of the cube, as SSAS allows you to build dimensions from multiple tables, as they can all be pulled together in the Data Source View (DSV).

The trouble starts, however, when you attempt to process the dimension built through multiple sources. As the data is being retreived from two different sources, SQL attempts to use the OPENROWSET function.

However, because the SQL Server Native Provider does not support the OPENROWSET function, it will return the following error:

'OLE DB error: OLE DB or ODBC error: Out-of-process use of OLE DB provider "SQLNCLI.1" with SQL Server is not supported.; 42000.'

While searching for a solution online, I came across multiple posts recommending to 'deselect' the materialize option in the define relationship window (in the dimension usage tab).

This, however, is an option only when there is a ‘referenced’ relationship between a dimension and the fact table.

Deselecting the materialize option in this case will prevent SQL from performing the join and therefore the OPENROWSET function will not be used.

However, this could lead to undesirable results and could have performance implications as well.

In addition to this, it does’nt solve the problem in situations where referencing is not defined at the design level.

For instance, in my case, the two table were referenced within a dimension and the dimension itself (which was composed of two tables in DSV) had a regular relationship with the fact table.

In such instances it is best to use an OLEDB provider instead of the Native SQL Server provider to build the data sources.