error when using "Referenced" dimension usage against an oracle data source

Hi All,

I've built a cube using a data source and DSV that point to an Oracle 10g database. I am able to process this cube so long as the dimensions are all related to the main fact table using regular dimension usage. The problem I'm having arises when the dimension has to have "referenced" usage through an intermediate dimension. In this case, when the cube processes, the SQL that gets generated and run looks akin to the following:

--

SELECT [CstOrds].[CstOrdsDISCOUNT0_0] AS [CstOrdsDISCOUNT0_0],[CstOrds].[CstOrdsBUY_QTY_DUE0_1] AS [CstOrdsBUY_QTY_DUE0_1],[CstOrds].[CstOrdsDESIRED_QTY0_2] AS [CstOrdsDESIRED_QTY0_2],[CstOrds].[CstOrdsQTY_ASSIGNED0_3] AS [CstOrdsQTY_ASSIGNED0_3],[CstOrds].[CstOrdsQTY_ON_ORDER0_4] AS [CstOrdsQTY_ON_ORDER0_4],[CstOrds].[CstOrdsQTY_PICKED0_5] AS [CstOrdsQTY_PICKED0_5],[CstOrds].[CstOrdsQTY_RETURNED0_6] AS [CstOrdsQTY_RETURNED0_6],[CstOrds].[CstOrdsQTY_SHORT0_7] AS [CstOrdsQTY_SHORT0_7],[CstOrds].[CstOrdsQTY_TO_SHIP0_8] AS [CstOrdsQTY_TO_SHIP0_8],[CstOrds].[CstOrdsQTY_SHIPPED0_9] AS [CstOrdsQTY_SHIPPED0_9],[CstOrds].[CstOrdsQTY_SHIPDIFF0_10] AS [CstOrdsQTY_SHIPDIFF0_10],[CstOrds].[CstOrdsQTY_INVOICED0_11] AS [CstOrdsQTY_INVOICED0_11],[CstOrds].[CstOrdsCOST0_12] AS [CstOrdsCOST0_12],[CstOrds].[CstOrdsNET_AMOUNT0_13] AS [CstOrdsNET_AMOUNT0_13],[CstOrds].[CstOrdsGROSS_AMOUNT0_14] AS [CstOrdsGROSS_AMOUNT0_14],[CstOrds].[CstOrdsSPTA0_15] AS [CstOrdsSPTA0_15],[CstOrds].[CstOrdsTCA0_16] AS [CstOrdsTCA0_16],[CstOrds].[CstOrds0_17] AS [CstOrds0_17],[CstOrds].[CstOrdsCUSTOMER_NO0_18] AS [CstOrdsCUSTOMER_NO0_18],[CstOrds].[CstOrdsINVOICE_DATE0_19] AS [CstOrdsINVOICE_DATE0_19],[CstOrds].[CstOrdsREAL_SHIP_DATE0_20] AS [CstOrdsREAL_SHIP_DATE0_20],[CstOrds].[CstOrdsPDDNT0_21] AS [CstOrdsPDDNT0_21],[CstOrds].[CstOrdsDENT0_22] AS [CstOrdsDENT0_22],[CstOrds].[CstOrdsORDER_NO0_23] AS [CstOrdsORDER_NO0_23],[CstOrds].[CstOrdsLINE_NO0_24] AS [CstOrdsLINE_NO0_24],[CstOrds].[CstOrdsREL_NO0_25] AS [CstOrdsREL_NO0_25],[CstOrds].[CstOrdsCATALOG_NO0_26] AS [CstOrdsCATALOG_NO0_26],[sPart_8].[PART_NO] AS [sPartPART_NO2_0]

FROM

OPENROWSET

(

N'OraOLEDB.Oracle',

N'detest';N'bi';N'',

N'

SELECT "DISCOUNT" "CstOrdsDISCOUNT0_0","BUY_QTY_DUE" "CstOrdsBUY_QTY_DUE0_1","DESIRED_QTY" "CstOrdsDESIRED_QTY0_2","QTY_ASSIGNED" "CstOrdsQTY_ASSIGNED0_3","QTY_ON_ORDER" "CstOrdsQTY_ON_ORDER0_4","QTY_PICKED" "CstOrdsQTY_PICKED0_5","QTY_RETURNED" "CstOrdsQTY_RETURNED0_6","QTY_SHORT" "CstOrdsQTY_SHORT0_7","QTY_TO_SHIP" "CstOrdsQTY_TO_SHIP0_8","QTY_SHIPPED" "CstOrdsQTY_SHIPPED0_9","QTY_SHIPDIFF" "CstOrdsQTY_SHIPDIFF0_10","QTY_INVOICED" "CstOrdsQTY_INVOICED0_11","COST" "CstOrdsCOST0_12","NET_AMOUNT" "CstOrdsNET_AMOUNT0_13","GROSS_AMOUNT" "CstOrdsGROSS_AMOUNT0_14","SALES_PRICE_TOTAL_API" "CstOrdsSPTA0_15","TOTAL_COST_API" "CstOrdsTCA0_16",1 "CstOrds0_17","CUSTOMER_NO" "CstOrdsCUSTOMER_NO0_18","INVOICE_DATE" "CstOrdsINVOICE_DATE0_19","REAL_SHIP_DATE" "CstOrdsREAL_SHIP_DATE0_20","PROMISED_DELIVERY_DATE_NO_TIME" "CstOrdsPDDNT0_21","DATE_ENTERED_NO_TIME" "CstOrdsDENT0_22","ORDER_NO" "CstOrdsORDER_NO0_23","LINE_NO" "CstOrdsLINE_NO0_24","REL_NO" "CstOrdsREL_NO0_25","CATALOG_NO" "CstOrdsCATALOG_NO0_26"

FROM "IAL"."BP_BI_CUSTOMER_ORDER_LINE"'

)

AS [CstOrds],

OPENROWSET

(

N'OraOLEDB.Oracle',

N'detest';N'bi';N'',

N'"IAL"."SALES_PART"'

)

AS [sPart_8]

WHERE

(

(

[CstOrds].[CstOrdsCATALOG_NO0_26] = [sPart_8].[CATALOG_NO]

)

)

The error that is returned when I run the query from SQL Server Management Studio is as follows:

Msg 7357, Level 16, State 2, Line 1

Cannot process the object ""IAL"."SALES_PART"". The OLE DB provider "OraOLEDB.Oracle" for linked server "(null)" indicates that either the object has no columns or the current user does not have permissions on that object.

Note that it seems to attempt to query the table behind the referenced dimension (SALES_PART) by simply opening the table, rather than selecting something specific from it. Unfortunately this doesn't work when processing the cube, nor does it work when I paste the same query into SQL Server Management Studio. However if I modify it a little to use

N'select * from "IAL"."SALES_PART"'

instead of just

N'"IAL"."SALES_PART"'

then it runs no problem. Is there any way to control the SQL that Analysis services produces to process the cube, or is there some other way to resolve this problem so I can include dimensions with "referenced" usage? (Note that I've tried with both the Microsoft and the Oracle OLEDB providers, in both cases the behaviour & error were the same)

Thanks in advance.

Kind regards,

Miles

Miles, do you have multiple data sources involved here?

What appears to be happening is that the server detects a remote data source for the intermediate dimension and has to use remote queries to join the results together.

Some choices would be:

- Avoid the need for the remote query if possible (this would improve performance). If all your data is really coming from the same data source, then maybe something has just been improperly configured and is incorrectly causing a remote query.

- Create a linked server between the SQL Server and the Oracle server and then point to the SQL Server as the source of the tables in the DSV. This would mean credentials from the SQL Server to the Oracle server would be saved as part of the linked server.

- Change the referenced dimension to be unmaterialized (there is a check box in the dimension usage dialog for referenced dimensions). This would mean that query performance might be impacted because the join between the two dimensions would have to be done at query time instead of during processing.

- Perhaps you can change the table in the DSV to look like SELECT * FROM "IAL"."SALES_PART"

HTH,

Akshai

|||

Hi Akshai,

You're absolutely right that there were 2 data sources involved. The eventual solution was to make the primary data source for my DSV the oracle one, and then it all started behaving itself properly. As you rightly pointed out, it was doing an unnecessary remote query, tunnelling the requests to Oracle through SQL server leading to all kinds of problems. When the queries go directly to oracle, it all works fine. Thanks for the reply :)

Kind regards,

Miles

error when using "Referenced" dimension usage against an oracle data source

Hi All,

I've built a cube using a data source and DSV that point to an Oracle 10g database. I am able to process this cube so long as the dimensions are all related to the main fact table using regular dimension usage. The problem I'm having arises when the dimension has to have "referenced" usage through an intermediate dimension. In this case, when the cube processes, the SQL that gets generated and run looks akin to the following:

--

SELECT [CstOrds].[CstOrdsDISCOUNT0_0] AS [CstOrdsDISCOUNT0_0],[CstOrds].[CstOrdsBUY_QTY_DUE0_1] AS [CstOrdsBUY_QTY_DUE0_1],[CstOrds].[CstOrdsDESIRED_QTY0_2] AS [CstOrdsDESIRED_QTY0_2],[CstOrds].[CstOrdsQTY_ASSIGNED0_3] AS [CstOrdsQTY_ASSIGNED0_3],[CstOrds].[CstOrdsQTY_ON_ORDER0_4] AS [CstOrdsQTY_ON_ORDER0_4],[CstOrds].[CstOrdsQTY_PICKED0_5] AS [CstOrdsQTY_PICKED0_5],[CstOrds].[CstOrdsQTY_RETURNED0_6] AS [CstOrdsQTY_RETURNED0_6],[CstOrds].[CstOrdsQTY_SHORT0_7] AS [CstOrdsQTY_SHORT0_7],[CstOrds].[CstOrdsQTY_TO_SHIP0_8] AS [CstOrdsQTY_TO_SHIP0_8],[CstOrds].[CstOrdsQTY_SHIPPED0_9] AS [CstOrdsQTY_SHIPPED0_9],[CstOrds].[CstOrdsQTY_SHIPDIFF0_10] AS [CstOrdsQTY_SHIPDIFF0_10],[CstOrds].[CstOrdsQTY_INVOICED0_11] AS [CstOrdsQTY_INVOICED0_11],[CstOrds].[CstOrdsCOST0_12] AS [CstOrdsCOST0_12],[CstOrds].[CstOrdsNET_AMOUNT0_13] AS [CstOrdsNET_AMOUNT0_13],[CstOrds].[CstOrdsGROSS_AMOUNT0_14] AS [CstOrdsGROSS_AMOUNT0_14],[CstOrds].[CstOrdsSPTA0_15] AS [CstOrdsSPTA0_15],[CstOrds].[CstOrdsTCA0_16] AS [CstOrdsTCA0_16],[CstOrds].[CstOrds0_17] AS [CstOrds0_17],[CstOrds].[CstOrdsCUSTOMER_NO0_18] AS [CstOrdsCUSTOMER_NO0_18],[CstOrds].[CstOrdsINVOICE_DATE0_19] AS [CstOrdsINVOICE_DATE0_19],[CstOrds].[CstOrdsREAL_SHIP_DATE0_20] AS [CstOrdsREAL_SHIP_DATE0_20],[CstOrds].[CstOrdsPDDNT0_21] AS [CstOrdsPDDNT0_21],[CstOrds].[CstOrdsDENT0_22] AS [CstOrdsDENT0_22],[CstOrds].[CstOrdsORDER_NO0_23] AS [CstOrdsORDER_NO0_23],[CstOrds].[CstOrdsLINE_NO0_24] AS [CstOrdsLINE_NO0_24],[CstOrds].[CstOrdsREL_NO0_25] AS [CstOrdsREL_NO0_25],[CstOrds].[CstOrdsCATALOG_NO0_26] AS [CstOrdsCATALOG_NO0_26],[sPart_8].[PART_NO] AS [sPartPART_NO2_0]

FROM

OPENROWSET

(

N'OraOLEDB.Oracle',

N'detest';N'bi';N'',

N'

SELECT "DISCOUNT" "CstOrdsDISCOUNT0_0","BUY_QTY_DUE" "CstOrdsBUY_QTY_DUE0_1","DESIRED_QTY" "CstOrdsDESIRED_QTY0_2","QTY_ASSIGNED" "CstOrdsQTY_ASSIGNED0_3","QTY_ON_ORDER" "CstOrdsQTY_ON_ORDER0_4","QTY_PICKED" "CstOrdsQTY_PICKED0_5","QTY_RETURNED" "CstOrdsQTY_RETURNED0_6","QTY_SHORT" "CstOrdsQTY_SHORT0_7","QTY_TO_SHIP" "CstOrdsQTY_TO_SHIP0_8","QTY_SHIPPED" "CstOrdsQTY_SHIPPED0_9","QTY_SHIPDIFF" "CstOrdsQTY_SHIPDIFF0_10","QTY_INVOICED" "CstOrdsQTY_INVOICED0_11","COST" "CstOrdsCOST0_12","NET_AMOUNT" "CstOrdsNET_AMOUNT0_13","GROSS_AMOUNT" "CstOrdsGROSS_AMOUNT0_14","SALES_PRICE_TOTAL_API" "CstOrdsSPTA0_15","TOTAL_COST_API" "CstOrdsTCA0_16",1 "CstOrds0_17","CUSTOMER_NO" "CstOrdsCUSTOMER_NO0_18","INVOICE_DATE" "CstOrdsINVOICE_DATE0_19","REAL_SHIP_DATE" "CstOrdsREAL_SHIP_DATE0_20","PROMISED_DELIVERY_DATE_NO_TIME" "CstOrdsPDDNT0_21","DATE_ENTERED_NO_TIME" "CstOrdsDENT0_22","ORDER_NO" "CstOrdsORDER_NO0_23","LINE_NO" "CstOrdsLINE_NO0_24","REL_NO" "CstOrdsREL_NO0_25","CATALOG_NO" "CstOrdsCATALOG_NO0_26"

FROM "IAL"."BP_BI_CUSTOMER_ORDER_LINE"'

)

AS [CstOrds],

OPENROWSET

(

N'OraOLEDB.Oracle',

N'detest';N'bi';N'',

N'"IAL"."SALES_PART"'

)

AS [sPart_8]

WHERE

(

(

[CstOrds].[CstOrdsCATALOG_NO0_26] = [sPart_8].[CATALOG_NO]

)

)

The error that is returned when I run the query from SQL Server Management Studio is as follows:

Msg 7357, Level 16, State 2, Line 1

Cannot process the object ""IAL"."SALES_PART"". The OLE DB provider "OraOLEDB.Oracle" for linked server "(null)" indicates that either the object has no columns or the current user does not have permissions on that object.

Note that it seems to attempt to query the table behind the referenced dimension (SALES_PART) by simply opening the table, rather than selecting something specific from it. Unfortunately this doesn't work when processing the cube, nor does it work when I paste the same query into SQL Server Management Studio. However if I modify it a little to use

N'select * from "IAL"."SALES_PART"'

instead of just

N'"IAL"."SALES_PART"'

then it runs no problem. Is there any way to control the SQL that Analysis services produces to process the cube, or is there some other way to resolve this problem so I can include dimensions with "referenced" usage? (Note that I've tried with both the Microsoft and the Oracle OLEDB providers, in both cases the behaviour & error were the same)

Thanks in advance.

Kind regards,

Miles

Miles, do you have multiple data sources involved here?

What appears to be happening is that the server detects a remote data source for the intermediate dimension and has to use remote queries to join the results together.

Some choices would be:

- Avoid the need for the remote query if possible (this would improve performance). If all your data is really coming from the same data source, then maybe something has just been improperly configured and is incorrectly causing a remote query.

- Create a linked server between the SQL Server and the Oracle server and then point to the SQL Server as the source of the tables in the DSV. This would mean credentials from the SQL Server to the Oracle server would be saved as part of the linked server.

- Change the referenced dimension to be unmaterialized (there is a check box in the dimension usage dialog for referenced dimensions). This would mean that query performance might be impacted because the join between the two dimensions would have to be done at query time instead of during processing.

- Perhaps you can change the table in the DSV to look like SELECT * FROM "IAL"."SALES_PART"

HTH,

Akshai

|||

Hi Akshai,

You're absolutely right that there were 2 data sources involved. The eventual solution was to make the primary data source for my DSV the oracle one, and then it all started behaving itself properly. As you rightly pointed out, it was doing an unnecessary remote query, tunnelling the requests to Oracle through SQL server leading to all kinds of problems. When the queries go directly to oracle, it all works fine. Thanks for the reply :)

Kind regards,

Miles

Error when assigning Dimension Data Permissions using AMO

Hello,

I am using AMO example posted on MSDN: http://msdn2.microsoft.com/en-us/library/ms345081.aspx

I followed this example very closely. I can create a role, assign read permissions to it, but when I try to

assign AllowedSet to Dimension Attribute (see code below):

// Get dimension and attribute

Dimension dim = dataBase.Dimensions.GetByName(dimName);

DimensionAttribute attr = dim.Attributes.GetByName("Group Name");

CubeDimensionPermission cubeDimPerm = cubePerm.DimensionPermissions.Add(dim.ID);

cubeDimPerm.Read = ReadAccess.Allowed;

AttributePermission attrPerm = cubeDimPerm.AttributePermissions.Add(attr.ID);

attrPerm.AllowedSet = "{[GroupUsers].[Group Name].&[0]}";

cubePerm.Update();

I am getting this error: Microsoft.AnalysisServices.AnalysisServicesClient.SendExecuteAndReadResponse(ImpactDetailCollection impacts, Boolean expectEmptyResults, Boolean throwIfError)
at Microsoft.AnalysisServices.AnalysisServicesClient.Alter(IMajorObject obj,
ObjectExpansion expansion, ImpactDetailCollection impact, Boolean allowCreate)
at Microsoft.AnalysisServices.Server.Update(IMajorObject obj, UpdateOptions o
ptions, UpdateMode mode, XmlaWarningCollection warnings, ImpactDetailCollection
impactResult)
at Microsoft.AnalysisServices.Server.SendUpdate(IMajorObject obj, UpdateOptio
ns options, UpdateMode mode, XmlaWarningCollection warnings, ImpactDetailCollect
ion impactResult)
at Microsoft.AnalysisServices.MajorObject.Update(UpdateOptions options, Updat
eMode mode, XmlaWarningCollection warnings)
at Microsoft.AnalysisServices.MajorObject.Update()
at IHS.Datawarehouse.CubeUtility.Program.AssignDimensionData(Database dataBas
e, String roleName, String dimName) in C:\IHS\WWBA\Development\Applications\IHS.
Datawarehouse.CubeUtility\IHS.Datawarehouse.CubeUtility\IHS.Datawarehouse.CubeUt
ility\Program.cs:line 99
at IHS.Datawarehouse.CubeUtility.Program.Main(String[] args) in C:\IHS\WWBA\D
evelopment\Applications\IHS.Datawarehouse.CubeUtility\IHS.Datawarehouse.CubeUtil
ity\IHS.Datawarehouse.CubeUtility\Program.cs:line 32

Has anyone experienced this error. What's causing this?

Actual error message in the event viewer:

The description for Event ID ( 22 ) in Source ( MSSQLServerOLAPService ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Internal error: An unexpected exception occured..

Error using UnaryOperatorColumn on a Many-to-Many linked dimension

Hi,
i made a small debugging environment for a problem i am getting, it has 2 fact and 2 dimension tables:

FactAccount - fact - (AccountKey,Balance)
DimAccount - dimension - (AccountKey,Code,Name)
BridgeAccountReport - fact - (AccountKey,ReportKey)
DimReport - dimension - (ReportKey,ParentReportKey,Code,Name,UnaryOperator)

the dimension usage is as follows:

for BridgeAccountReport
DimAccount - Regular
DimReport - Regular

for FactAccount
DimAccount - Regular
DimReport - Many-to-Many using BridgeAccountReport as intermediate fact table

DimReport has a self-referencing hierarchy using ParentReportKey.

The idea is to be able to use the same facts recorded at the DimAccount level under different analysis structures recorded in DimReport.

The problem i am getting is that the UnaryOperatorColumn is only having an effect on the inmediate superior level,
but the result on that level is not afterwards used to calculate the aggregations on upper levels.

Here is a sample result:

Net profit 53 (NO typing error!!)
Profit 6
Income 28
Expenses 22 (unary operator set to '-')
Taxes 3

Profit, which is correctly calculated based on unary operator as 6 is not the used as it is to calculate Net Profit which ends up with a value of 53.
Instead the full values of the lower levels seem to be used to calculate it.

To contrast these results i made a similar example, but this time with only:

FactAccount (AccountKey,Balance)
DimAccount (AccountKey,ParentAccountKey,Code,Name,UnaryOperatorColumn)

and i get:

Net profit 9
Profit 6
Income 28
Expenses 22 (unary operator set to '-')
Taxes 3

Correct results.

So, the difference must be somehow related to the indirect relation over the many-to-many link.

Am i forgetting something? Is it a bug in analysis services?

thanks for any hint or comment, af.Hi,
I have encountered the same problem. On the leaf level the unary operator is considered, but on higher level it is ignored.

Have you found any solution or workaround?

Any hint would be helpful ...thx.|||Hi, so i am not crazy :-)
Yours is the first answer i got both from this forum and from the Connect bug report which you can visit here:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=200152

I was also planning to describe this more in detail in a forum dedicated to many-to-many relations but i couldnt find the time so far. The forum is in:
http://www.sqlbi.eu/Forum/tabid/72/forumid/17/scope/threads/Default.aspx

On that site there is also an excellent paper on many-to-many modelling.

Let me know if you find some answer to this problem.

af.

Error using UnaryOperatorColumn on a Many-to-Many linked dimension

Hi,
i made a small debugging environment for a problem i am getting, it has 2 fact and 2 dimension tables:

FactAccount - fact - (AccountKey,Balance)
DimAccount - dimension - (AccountKey,Code,Name)
BridgeAccountReport - fact - (AccountKey,ReportKey)
DimReport - dimension - (ReportKey,ParentReportKey,Code,Name,UnaryOperator)

the dimension usage is as follows:

for BridgeAccountReport
DimAccount - Regular
DimReport - Regular

for FactAccount
DimAccount - Regular
DimReport - Many-to-Many using BridgeAccountReport as intermediate fact table

DimReport has a self-referencing hierarchy using ParentReportKey.

The idea is to be able to use the same facts recorded at the DimAccount level under different analysis structures recorded in DimReport.

The problem i am getting is that the UnaryOperatorColumn is only having an effect on the inmediate superior level,
but the result on that level is not afterwards used to calculate the aggregations on upper levels.

Here is a sample result:

Net profit 53 (NO typing error!!)
Profit 6
Income 28
Expenses 22 (unary operator set to '-')
Taxes 3

Profit, which is correctly calculated based on unary operator as 6 is not the used as it is to calculate Net Profit which ends up with a value of 53.
Instead the full values of the lower levels seem to be used to calculate it.

To contrast these results i made a similar example, but this time with only:

FactAccount (AccountKey,Balance)
DimAccount (AccountKey,ParentAccountKey,Code,Name,UnaryOperatorColumn)

and i get:

Net profit 9
Profit 6
Income 28
Expenses 22 (unary operator set to '-')
Taxes 3

Correct results.

So, the difference must be somehow related to the indirect relation over the many-to-many link.

Am i forgetting something? Is it a bug in analysis services?

thanks for any hint or comment, af.Hi,
I have encountered the same problem. On the leaf level the unary operator is considered, but on higher level it is ignored.

Have you found any solution or workaround?

Any hint would be helpful ...thx.|||Hi, so i am not crazy :-)
Yours is the first answer i got both from this forum and from the Connect bug report which you can visit here:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=200152

I was also planning to describe this more in detail in a forum dedicated to many-to-many relations but i couldnt find the time so far. The forum is in:
http://www.sqlbi.eu/Forum/tabid/72/forumid/17/scope/threads/Default.aspx

On that site there is also an excellent paper on many-to-many modelling.

Let me know if you find some answer to this problem.

af.