|
|
You're in the
sql server dts
group:calling SSIS package from stored procedure
sql server dts:
SSIS package. I was going to use the DTexec utilility but have not found out how to call that utility from a stored procedure. Is the the right approach or is there a better way? Is there an alternate way to call an SSIS package from a stored procedure? any help is appreciated. Thanks. Dave Christman
Darren - I have setup a sp to execute dtexec using xp_cmdshell and this is
working great as long as the user is in the sysadmin db role. I understand that if a non-sysadmin user executes my sp, SQL Server 2005 will attempt to use the cmd shell proxy account - if it doesn't exist the exec will fail. I have created a local Windows account and used this account for the cmd shell proxy credential. When the non-sysadmin user attempts to execute my sp, the proc returns the following error. What am i missing? Microsoft OLE DB Provider for SQL Server error '80040e09' EXECUTE permission denied on object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'. [quoted text, click to view] "Darren Green" wrote:
> Hello hedgracer, > > > I am going to have a stored procedure that will call and execute an > > SSIS package. I was going to use the DTexec utilility but have not > > found out how to call that utility from a stored procedure. Is the the > > right approach or is there a better way? Is there an alternate way to > > call an SSIS package from a stored procedure? any help is appreciated. > > Thanks. > > > > Dave Christman > > > > The xp_cmdshell extended stored procedure allows you to command line programs > > The only other alternative is to create a job, and then call sp_start_job. > >
Thank you Darren - I appreciate the response. Yes, I thought the error msg
was pretty clear too and did grant execute permissions to xp_cmdshell for the application login. This did not work either. And like you, I am concerned with the security implications of doing so. Let me take this from a different approach. Is there a means to use the SSIS/DTS object model, .NET, and CLR integration to execute a SSIS package from a stored procedure? [quoted text, click to view] "Darren Green" wrote:
> Hello SSM, > > The error message looks pretty clear to me, how about granting permissions > on xp_cmdshell to your user (the one making the connection to SQL Server > to call xp_cmshell), have you done that? > > This is a bad idea though from a security perspective though, please be aware > of that. > > Darren > > > Darren - I have setup a sp to execute dtexec using xp_cmdshell and > > this is working great as long as the user is in the sysadmin db role. > > I understand that if a non-sysadmin user executes my sp, SQL Server > > 2005 will attempt to use the cmd shell proxy account - if it doesn't > > exist the exec will fail. I have created a local Windows account and > > used this account for the cmd shell proxy credential. When the > > non-sysadmin user attempts to execute my sp, the proc returns the > > following error. What am i missing? > > > > Microsoft OLE DB Provider for SQL Server error '80040e09' > > > > EXECUTE permission denied on object 'xp_cmdshell', database > > 'mssqlsystemresource', schema 'sys'. > > > > "Darren Green" wrote: > > > >> Hello hedgracer, > >> > >>> I am going to have a stored procedure that will call and execute an > >>> SSIS package. I was going to use the DTexec utilility but have not > >>> found out how to call that utility from a stored procedure. Is the > >>> the right approach or is there a better way? Is there an alternate > >>> way to call an SSIS package from a stored procedure? any help is > >>> appreciated. Thanks. > >>> > >>> Dave Christman > >>> > >> The xp_cmdshell extended stored procedure allows you to command line > >> programs > >> > >> The only other alternative is to create a job, and then call > >> sp_start_job. > >> > >
Hello hedgracer,
[quoted text, click to view] > I am going to have a stored procedure that will call and execute an > SSIS package. I was going to use the DTexec utilility but have not > found out how to call that utility from a stored procedure. Is the the > right approach or is there a better way? Is there an alternate way to > call an SSIS package from a stored procedure? any help is appreciated. > Thanks. > > Dave Christman > The xp_cmdshell extended stored procedure allows you to command line programs The only other alternative is to create a job, and then call sp_start_job.
I resolved my issue with xp_cmdshell as follows....
I had already tried granting the user execution permissions to the sp without success (I did not want to create this security hole either)- I started getting a different error message. One related to the object being closed. I thought this error message was related to cmdshell. After some research, I found this error message was related to an empty recordset being returned to ASP. After some further research, I found that the command line statement was reporting that it could not open the SSIS package. This was hidden by the no_output clause in the cmdshell execution. After working through this, I found that I did setup the Windows account and cmdshell proxy correctly. I also had the Windows account setup as a database login with sysadmin database role correctly. The additional steps I took were adding the 'with execute as owner' clause to the stored procedure being executed and giving the Windows account permissions to the file subdir where I store the SSIS packages. [quoted text, click to view] "SSM" wrote:
> Thank you Darren - I appreciate the response. Yes, I thought the error msg > was pretty clear too and did grant execute permissions to xp_cmdshell for the > application login. This did not work either. And like you, I am concerned > with the security implications of doing so. Let me take this from a > different approach. Is there a means to use the SSIS/DTS object model, .NET, > and CLR integration to execute a SSIS package from a stored procedure? > > "Darren Green" wrote: > > > Hello SSM, > > > > The error message looks pretty clear to me, how about granting permissions > > on xp_cmdshell to your user (the one making the connection to SQL Server > > to call xp_cmshell), have you done that? > > > > This is a bad idea though from a security perspective though, please be aware > > of that. > > > > Darren > > > > > Darren - I have setup a sp to execute dtexec using xp_cmdshell and > > > this is working great as long as the user is in the sysadmin db role. > > > I understand that if a non-sysadmin user executes my sp, SQL Server > > > 2005 will attempt to use the cmd shell proxy account - if it doesn't > > > exist the exec will fail. I have created a local Windows account and > > > used this account for the cmd shell proxy credential. When the > > > non-sysadmin user attempts to execute my sp, the proc returns the > > > following error. What am i missing? > > > > > > Microsoft OLE DB Provider for SQL Server error '80040e09' > > > > > > EXECUTE permission denied on object 'xp_cmdshell', database > > > 'mssqlsystemresource', schema 'sys'. > > > > > > "Darren Green" wrote: > > > > > >> Hello hedgracer, > > >> > > >>> I am going to have a stored procedure that will call and execute an > > >>> SSIS package. I was going to use the DTexec utilility but have not > > >>> found out how to call that utility from a stored procedure. Is the > > >>> the right approach or is there a better way? Is there an alternate > > >>> way to call an SSIS package from a stored procedure? any help is > > >>> appreciated. Thanks. > > >>> > > >>> Dave Christman > > >>> > > >> The xp_cmdshell extended stored procedure allows you to command line > > >> programs > > >> > > >> The only other alternative is to create a job, and then call > > >> sp_start_job. > > >> > > > >
Hello SSM,
The error message looks pretty clear to me, how about granting permissions on xp_cmdshell to your user (the one making the connection to SQL Server to call xp_cmshell), have you done that? This is a bad idea though from a security perspective though, please be aware of that. Darren [quoted text, click to view] > Darren - I have setup a sp to execute dtexec using xp_cmdshell and > this is working great as long as the user is in the sysadmin db role. > I understand that if a non-sysadmin user executes my sp, SQL Server > 2005 will attempt to use the cmd shell proxy account - if it doesn't > exist the exec will fail. I have created a local Windows account and > used this account for the cmd shell proxy credential. When the > non-sysadmin user attempts to execute my sp, the proc returns the > following error. What am i missing? > > Microsoft OLE DB Provider for SQL Server error '80040e09' > > EXECUTE permission denied on object 'xp_cmdshell', database > 'mssqlsystemresource', schema 'sys'. > > "Darren Green" wrote: > >> Hello hedgracer, >> >>> I am going to have a stored procedure that will call and execute an >>> SSIS package. I was going to use the DTexec utilility but have not >>> found out how to call that utility from a stored procedure. Is the >>> the right approach or is there a better way? Is there an alternate >>> way to call an SSIS package from a stored procedure? any help is >>> appreciated. Thanks. >>> >>> Dave Christman >>> >> The xp_cmdshell extended stored procedure allows you to command line >> programs >> >> The only other alternative is to create a job, and then call >> sp_start_job. >>
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |