dbTalk Databases Forums  

Bug? -- Same MDX returns different result sets

microsoft.public.sqlserver.olap microsoft.public.sqlserver.olap


Discuss Bug? -- Same MDX returns different result sets in the microsoft.public.sqlserver.olap forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
BBH
 
Posts: n/a

Default Bug? -- Same MDX returns different result sets - 02-25-2005 , 02:25 PM






I have a MDX query which includes a very simple calculated member. The query
returns correct number when I run it through the Sample MDX Application or
any other client applications. However, when I try to run the same query
using OPENQUERY statement (the Analysis Services is set up as linked server),
the calculated member returns null. Looks like the calculation for the
calculated member never got triggered. And ideas?

Thanks.

Reply With Quote
  #2  
Old   
Dave Wickert [MSFT]
 
Posts: n/a

Default Re: Bug? -- Same MDX returns different result sets - 02-25-2005 , 06:04 PM






Security?
The domain account that the SQL service is running under must allow access
to the AS server (i.e. is it a domain account common between the RDBMS and
AS machines and does it have access to the cube? is there an Everyone role
in the cube?)

Can you see other measures? e.g. in the same cube? same database? same
server (i.e. can you see Foodmart?)

--
Dave Wickert [MSFT]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.

"BBH" <BBH (AT) discussions (DOT) microsoft.com> wrote

Quote:
I have a MDX query which includes a very simple calculated member. The
query
returns correct number when I run it through the Sample MDX Application or
any other client applications. However, when I try to run the same query
using OPENQUERY statement (the Analysis Services is set up as linked
server),
the calculated member returns null. Looks like the calculation for the
calculated member never got triggered. And ideas?

Thanks.



Reply With Quote
  #3  
Old   
BBH
 
Posts: n/a

Default Re: Bug? -- Same MDX returns different result sets - 02-25-2005 , 10:47 PM



It should not be a security issue. I was doing testing on a local machine
with SQL server and AS both installed. SQL service is running under local
administrator account which is also in the OLAP administrator group. The
OPENQUERY is embedded within a stored procedure running by system
administrator (windows authentication). Everything is tested on a local
machine, no net work is involved.

"Dave Wickert [MSFT]" wrote:

Quote:
Security?
The domain account that the SQL service is running under must allow access
to the AS server (i.e. is it a domain account common between the RDBMS and
AS machines and does it have access to the cube? is there an Everyone role
in the cube?)

Can you see other measures? e.g. in the same cube? same database? same
server (i.e. can you see Foodmart?)

--
Dave Wickert [MSFT]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.

"BBH" <BBH (AT) discussions (DOT) microsoft.com> wrote in message
news:760C193E-507B-4F70-A0DB-8481E47248CE (AT) microsoft (DOT) com...
I have a MDX query which includes a very simple calculated member. The
query
returns correct number when I run it through the Sample MDX Application or
any other client applications. However, when I try to run the same query
using OPENQUERY statement (the Analysis Services is set up as linked
server),
the calculated member returns null. Looks like the calculation for the
calculated member never got triggered. And ideas?

Thanks.




Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.