![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I've found the reason why ... I had scheduled the job on another server and generated a SQL script from the job. Then I installed the package on another SQL server and installed the job from the script. The job was running the DTS package on the original SQL Server. I now understand the encrpted DSTRUN command generated is NOT portable. "Craig" wrote: Hi I have scheduled a DTS package which works fine. The last step in the package is a T-SQL task. I changed the T-SQL task and reran the scheduled job but it ran the original version. I removed the original version but the scheduled job still ran the original version. I restarted SQL Agent and SQL Server but the result is the same. Any suggestions? -- Regards, Craig |
#3
| |||
| |||
|
|
Thanks for posting back Craig. I never use the functionality of right clicking on a package and use the Schedule Package. The encrypted command line can make it difficult to troubleshoot job issues or to move the jobs to other servers. I generally set packages up as jobs by manually creating the job and the dtsrun command and using windows authentication for the login. There isn't much that needs to be encrypted then - unless you don't want job owners or sysadmins to know what package is running in which job. -Sue |
#4
| |||
| |||
|
|
In message <siprj05t5k56tsn0f1k2b2rgvqn6301dvm (AT) 4ax (DOT) com>, Sue Hoegemeier Sue_H (AT) nomail (DOT) please> writes Thanks for posting back Craig. I never use the functionality of right clicking on a package and use the Schedule Package. The encrypted command line can make it difficult to troubleshoot job issues or to move the jobs to other servers. I generally set packages up as jobs by manually creating the job and the dtsrun command and using windows authentication for the login. There isn't much that needs to be encrypted then - unless you don't want job owners or sysadmins to know what package is running in which job. -Sue I'm with Sue on this one, rarely any need for encrypted command lines. You may find this useful for manually building command lines- Getting Syntax Help for DTSRun (http://www.sqldts.com/default.aspx?301) -- Darren Green (SQL Server MVP) DTS - http://www.sqldts.com PASS - the definitive, global community for SQL Server professionals http://www.sqlpass.org |
#5
| |||
| |||
|
|
I would prefer it if the Generate SQL Script option did not generate an encrypted command line. Regards Craig "Darren Green" wrote: In message <siprj05t5k56tsn0f1k2b2rgvqn6301dvm (AT) 4ax (DOT) com>, Sue Hoegemeier Sue_H (AT) nomail (DOT) please> writes Thanks for posting back Craig. I never use the functionality of right clicking on a package and use the Schedule Package. The encrypted command line can make it difficult to troubleshoot job issues or to move the jobs to other servers. I generally set packages up as jobs by manually creating the job and the dtsrun command and using windows authentication for the login. There isn't much that needs to be encrypted then - unless you don't want job owners or sysadmins to know what package is running in which job. -Sue I'm with Sue on this one, rarely any need for encrypted command lines. You may find this useful for manually building command lines- Getting Syntax Help for DTSRun (http://www.sqldts.com/default.aspx?301) -- Darren Green (SQL Server MVP) DTS - http://www.sqldts.com PASS - the definitive, global community for SQL Server professionals http://www.sqlpass.org |
![]() |
| Thread Tools | |
| Display Modes | |
| |