Re: Processing Cube from different machine
- From: "Avadhanam" <avadhanam@xxxxxxxxxxxxxxxxx>
- Date: Fri, 28 Oct 2005 11:56:36 +0530
We have evaluated this process already and it worked fine at our development
phase.
But at client place our application do not get SysAdmin rights
Thanks
Murali
"Darren Gosbell" <xxx@xxxxxxx> wrote in message
news:MPG.1dcabead941c52ea98977a@xxxxxxxxxxxxxxxxxxxxx
>
>> While in general, you can definitely process an Olap database which is on
>> another server, you could always have your DSO scripts running on the
>> Olap
>> server (Server 1 in this case) and have something like NT Scheduled Tasks
>> or
>> SQL Job Agent perform the task of processing for you?
>
> Another twist to this would be to kick off the DSO task from a stored
> proc or if you are brave you can use the sp_OACreate family of extended
> stored procs and write the DSO code in a stored procedure.
>
> Beware that both these approaches require opening up the security on the
> SQL server. I have not double checked in BOL, but I am that in order to
> run the sp_OACreate procedures the user needs to have SysAdmin rights to
> SQL Server. And there is a property you need to set to allow non SA
> users to run external commands (such as kick of a DSO VBScript)
>
>
> --
> Regards
> Darren Gosbell [MCSD]
> <dgosbell_at_yahoo_dot_com>
> Blog: http://www.geekswithblogs.net/darrengosbell
.
- References:
- Processing Cube from different machine
- From: Avadhanam
- Re: Processing Cube from different machine
- From: Denny Lee
- Processing Cube from different machine
- Prev by Date: Re: Processing Cube from different machine
- Next by Date: Re: Replacing a set of data in cube
- Previous by thread: Re: Processing Cube from different machine
- Next by thread: Re: Problem with user-defined functions in dimension definitions
- Index(es):
Relevant Pages
|
