I am trying to bring up our DTS and SQL Server Agent Jobs Sorbox compliant.  I am trying to decipher the DTSRun~/ (Long Numeric String) in each step within each job.  There is no easy way.

I have looked inside msdb but it also has this long numeric string.  Does anyone know how to decipher this long string or where in msdb it exist.  Thanks.

In the DTS GUI, the package and version GUIDs are in the package properties dialog box.  You can find the package name in msdb..sysdtspackages like this:

SELECT     name
FROM         sysdtspackages
WHERE     (id = '{55521ACB-1643-45CD-B882-A6AB20FF59F8}') OR
                      (versionid = '{67B35377-A60B-4EC8-A240-184CFD12834E}')

Fields:

name is the package name

id is the package GUID

versionid is the version GUID

If you have the Wrox SQL Server 2000 DTS book, see page 69 to read about the switches.

Thanks Jules.

I have gone through this process and able to look at the GUIID and Version ID. I am needing to decipher the DTS RUN Cmd inside the Server Agent - Jobs. 

There is a tool that I am trying to use - DecDTSRun.c.  It is written in C and I do not have much experience in C.  Are you familiar with this tool.

Ernest

No, sorry, not familiar with the tool. 

Do you simply need to query sysjobsteps?  The command field has the dts run command in it.

I am needing to decrypt the string (DTSPackage) after the dtsrun command so that I am able to see which package is attached to each job.  Sort of...reverse engineer.  My other alternative is to recreate the jobs; however, this process is much to tediuos.

Up to this point, I haven't found a method to decrypt this string.

Ernest

In the future, when you schedule a dts package as a job - say using dtsrunui, simply don't check "encrypt" when you generate the command string.  Or create the string manually in EM.  Don't right click on the package to schedule - that always creates an encrypted command string.  If that is the reason that you have encrypted command strings in the first place, then you may be in luck - because the name of the dts package being executed will be in the name field of sysjobsteps unless someone manually changed the name of the step.  But that's a pretty big leap of faith. I don't think you should be able to decrypt the string once encrypted.  I guess that's kind of the point, eh?  Given that that is the case, you can't prove that a dtsrun command really does what you say it does unless you re-write it yourself without encryption.  Sure it's a hassle but it's probably the right thing to do.

You shouldn't be able to, but you can...

Of course compiling C programs will drive a non-c programmer crazy.  They distribute their programs uncompiled just to piss everyone off.

Hi, I have the same problem.

Did you finally find a solution for this ??

If not, where did you find the DecDTSRun.c ??

Thank's

Sylvio

I found the C at the following link.  I hope that you have better luck.  I am still working on this item.

http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26

Ernest