SSIS shedule job error

  • Good morning.

     

    I moved over a DTS package from 2000 to 2005 and updated all of the connection information. If I run the package directly it works, but when I run it from the job scheduler it comes back with the following error message:

     

    Message

    Executed as user: Domain\Admin. The command line parameters are invalid.  The step failed.

    I know it is something simple but I cannot see the forest through the trees.

    Any suggestions

     

    Thanks


    Stacey W. A. Gregerson

  • Stacey,

    Are you storing the package as a legacy DTS package and running it using DTSRun?  If so, are you using the GUID to identify the package?  I found that packages moved to SQL 2005 get a new GUID when they're saved and I had to regenerate the DTSRun command in my jobs to use the new GUID.

    Also, the parameters for dtexec (the new SQL2005 run utility) are different than those for DTSRun.

    Greg

    Greg

  • Did you install DTS addins (SQLServer2005_DTS.msi) for sql server 2005?

    http://www.microsoft.com/downloads/details.aspx?familyid=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en

     

    MohammedU
    Microsoft SQL Server MVP

  • Additional information:

     

    This is a DTS package from SQL Server 2000  I can execute the package under DTS Legacy\Data transformation Services.

    I know that I have a lot of cleanup work for the one that I migrated to SQL Server,  and that is the one that does not work, big surprise.

    So my question is how do I execute the legacy package from SQL Server agent jobs. (only until I re-write this huge(17 different connections to servers) kluge package that some else wrote. Don't get me started on this hunk of stuff they wrote)

     


    Stacey W. A. Gregerson

  • Aside from the GUID thing I mentioned, I didn't have any trouble running a legacy DTS package in a job in SQL 2005.  I guess you should make sure the job step that has the DTSRUN command in it has "Operating system(cmdexec)" as the type and "SQL Agent Service Account" as Run As.  Also, make sure the SQL Server Agent uses a domain account since it accesses other servers.

    Greg

    Greg

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply