Create Job From Package

Trying to re-create a job after creating a new package. Old job was called
with the following synax:
DTSRun
/~Z0x322A50F270D63181ED3C87B10CDFB82666EFD66DAA4A08 5A03A8BC5BE88F8ED29DDEA7B407C5035D24F856D65611E761 9014C84B379DD1CCDEDB18D65E657D60798D4F56B37D443D16 CE7A685E612C69DA8A82131E8A281EED2D73345D8E942D9BAE 8B20CB8A6844A569E61F23A0079738A695D8847C6811CFF198 6E161BE2D3A581BE388FDF14D4703D00
Where is this number located? Can this package be called using the syntax:
DTSRUN /N 'Name of my Package'
?
Regards,
Jamie
As my reply previously...
the easiest thing to do is to use DTSRUNUI to generate human-readable
command-line arguments and enter these in your DTS scheduled jobs, provided
they don't include passwords ie overwrite these arguments. The command you
have is encrypted and I don't know of any way to have it unencrypted. If
your question is how to relate this job to the parent DTS package, then the
name of the job should be the same as the package name.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Is this done to hide the sa password? I'm not sure why it would have been
encrypted. Must the permissions all coincide with the agent user-login if
those permissions are not run as sa? What might happen if the previous dba's
role/permissions on the database are no longer "systemadmin" and the job runs
under the context of their login?
Regards,
Jamie
"Paul Ibison" wrote:

> As my reply previously...
> the easiest thing to do is to use DTSRUNUI to generate human-readable
> command-line arguments and enter these in your DTS scheduled jobs, provided
> they don't include passwords ie overwrite these arguments. The command you
> have is encrypted and I don't know of any way to have it unencrypted. If
> your question is how to relate this job to the parent DTS package, then the
> name of the job should be the same as the package name.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||Jamie,
encrypting passwords is one reason it's useful - I certainly wouldn't want
my sa password in plain text hanging around
I generally prefer trusted security anyway for these packages. If not,
you'll have a sysadmin password available or have to encrypt the whole line
(or set up a proxy). The ideal solution for myself is to be able to read the
command line in the job to see what it is doing, and not have a security
worry, so trusted security fits the bill.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .