One more question regarding Reporting action

All the reporting action samples I read from AdventureWorks, when pass link and parameter to the report in reporting service, is linked to the report as Analysis Service data source based report.

I am wondering if reporting action can pass parameter to regular relational db based reporting service report not Analysis Service data source based report.

If yes, could you share a simple sample?

I can't see why the data source of a report would matter, when using a reporting action. The Adventure Works examples may all be using an Analysis Services data source just for convenience. Have you tried editing an existing Adventure Works reporting action, to point to a relational report instead?|||

Hi Deepak, thank you so much for your reply! Yes, I did try the following using AW AS and AW sample reports RS projects:

Here is my reporting action:

Name: Sales Order Detail

Target Type: Dimension members

Target object: Internet Sales Order Detail

ReportServer:localhost

ReportPath:ReportServer?/AdventureWorks Sample Reports/Sales Order Detail

Parameters NamealesOrderNumber (Match the one at Sales Order Detail report

Parameter Value: [Internet Sales Order Details].[Sales Order Number].[Sales Order Number].CurrentMember.Name

And I make sure Sales Order Detail Report is running correctly and parameter is matching the parameter name I defined at the cube reporting action. Then I deploy the cube, however when drop the Sale Order Number dimension and right click, there is no Reporting Action showing up.

Could you give me some pointers?

Thanks

|||

Did you configure the "Caption", under "Additional Properties" - if not, you can refer to the Adventure Works "Sales Reason Comparisons" action, whose Caption is defined as an MDX expression:

"Sales Reason Comparisons for " +

[Product].[Category].CurrentMember.Member_Caption + "..."

|||

Thanks again. Just did that and deployed.

"Sales Reason Comparisons for " + [Internet Sales Order Details].[Sales Order Number].[Sales Order Number].CurrentMember.Member_Caption + "..."

However reporting action is still not showing. Deepak, anything else I miss?

Thanks

|||Can't think of anything else - are you able to see the standard Reporting action which comes with Adventure Works, ie. "Sales Reason Comparisons"? If so, I would suggest making a test copy of Adventure Works, and progressively modifying this action to incorporate your report in small steps, till it breaks - or maybe it doesn't break!

One last xp_cmdshell Q (sorry)

I run the below on the box that has psExec installed as sa (dbo) in QA.
The MSSQLSERVER service is set to Local Account.
Domain\Administrator will run c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat
from a CmdExec job sucessfully. I run same from command prompt successfully.
Do I have to set MSSQLSERVER agent to start as admin.?
Or can I explicitly say exec master.Domain\Administrator.cp_cmdshell or
similar?
Even our DBA is stumped!!
EXEC xp_cmdshell 'c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat' ;
output
---
NULL
PsExec v1.60 - Execute processes remotely
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com
NULL
Access is denied.
Connecting to 10.2.27.230...
Couldn't access 10.2.27.230:
NULL
It looks like psExec doesn't have permission but it is SQL QA that is the
sourcer of the problem.Local Account? or Local System? The SQL Server service must execute with
the credentials needed to execute commands on the other computer. It cannot
execute as Local System. It must execute as a domain user account.
WARNING!!! It is extremely dangerous to use xp_cmdshell in this way. It is
even more dangerous to run as a domain admin. If you're a consultant, be
sure you have a battalion of lawyers in your pocket and review your
professional insurance contract, because it would be a simple thing for a
smart lawyer to prove gross negligence on your part.
"marcmc" <marcmc@.discussions.microsoft.com> wrote in message
news:642C7D5B-DA48-427D-9535-0BF66E90ADA4@.microsoft.com...
> I run the below on the box that has psExec installed as sa (dbo) in QA.
> The MSSQLSERVER service is set to Local Account.
> Domain\Administrator will run c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat
> from a CmdExec job sucessfully. I run same from command prompt
successfully.
> Do I have to set MSSQLSERVER agent to start as admin.?
> Or can I explicitly say exec master.Domain\Administrator.cp_cmdshell or
> similar?
> Even our DBA is stumped!!
> EXEC xp_cmdshell 'c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat' ;
> output
> ---
> NULL
> PsExec v1.60 - Execute processes remotely
> Copyright (C) 2001-2005 Mark Russinovich
> Sysinternals - www.sysinternals.com
> NULL
> Access is denied.
> Connecting to 10.2.27.230...
>
> Couldn't access 10.2.27.230:
> NULL
> It looks like psExec doesn't have permission but it is SQL QA that is the
> sourcer of the problem.|||thx again, what are the alternatives, create an account and lock it down,
maybe? or
"Brian Selzer" wrote:

> Local Account? or Local System? The SQL Server service must execute with
> the credentials needed to execute commands on the other computer. It cann
ot
> execute as Local System. It must execute as a domain user account.
> WARNING!!! It is extremely dangerous to use xp_cmdshell in this way. It i
s
> even more dangerous to run as a domain admin. If you're a consultant, be
> sure you have a battalion of lawyers in your pocket and review your
> professional insurance contract, because it would be a simple thing for a
> smart lawyer to prove gross negligence on your part.
> "marcmc" <marcmc@.discussions.microsoft.com> wrote in message
> news:642C7D5B-DA48-427D-9535-0BF66E90ADA4@.microsoft.com...
> successfully.
>
>|||Create an external process to do whatever it is you need to do. Then you
don't have to worry about the xp_cmdshell security hole. Another solution
is to use replication, but if you can't, then you can queue up the
information in a table and create a dequeue process to move it. Both of
these solutions is more robust, because you can still collect information if
the other system is down.
"marcmc" <marcmc@.discussions.microsoft.com> wrote in message
news:97BD8606-7F5A-4904-B13C-533FE167A77D@.microsoft.com...
> thx again, what are the alternatives, create an account and lock it down,
> maybe? or
> "Brian Selzer" wrote:
>
with
cannot
is
be
a
QA.
cmdmgr_Resume.bat
or
the|||On Wed, 7 Sep 2005 05:46:10 -0700, marcmc wrote:

>I run the below on the box that has psExec installed as sa (dbo) in QA.
>The MSSQLSERVER service is set to Local Account.
>Domain\Administrator will run c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat
>from a CmdExec job sucessfully. I run same from command prompt successfully
.
>Do I have to set MSSQLSERVER agent to start as admin.?
>Or can I explicitly say exec master.Domain\Administrator.cp_cmdshell or
>similar?
>Even our DBA is stumped!!
Hi marcmc,
(S)he should check out what BOL says about services accounts.
If you really want to do it like this, than the least unsafe way is to:
a) Have your network administrator set up a domain account for use by
the SQL Server service. Make sure to change the password policy to not
automatically age the password.
b) Give this account all privileges required for SQL Server operation,
plus all privileges required to run your batch file. Don't give any
other privileges to this account. If your version of windows allows it,
disable the posibility to log on using this account as a normal user
(i.e. make it an account that can only be used by services)
c) Change the startup parameters for your SQL Server instance to log in
using this account instead of logging in as Local System.
d) Keep your fingers crossed :-)
But I agree with Brian that there are other ways to do this, and that
they are probably better!
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

OLEDB error while processing Analysis service database

Hi,
I migrated AS 2000 database to AS 2005 thorugh migration wizard and started processing the database. But I am getting error like "OLE DB error: OLE DB or ODBC error: Query (5, 19) Parser: The syntax for 'AS' is incorrect..". After migrating I didn't modified any settings.
If anybody having info, please share.
ThanksIt looks the SQL query sent by Analysis Services for processing is bad. You can examine the query in the processing dialog and see what's wrong (wrong syntax for AS clause?).