Automating DTS Execution
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/gcarnu/automatingdtsexecution.asp
-
good article.
Thanks for the information supplied.
-
"If you were to replace the Child package for some reason, like saving it after making changes, this would create a completely new VersionID, with a new time stamp and a new ProgramID! And this would break the linkage between packages, as the VersionID is pointing to an old VersionID with the same name. The PackageID {543E….184} in the background of Figure 2 is obsolete, and the execution will fail!"
This is not strictly true. When choosing the package for an Execute Package Task, point to the package name instead of a specific version and the task will always use the latest version. You can make changes to the child package (which will change the versionId) but the packageId will not change so the Execute Package Task will not need to be updated.
-
Hi,
I too find quite unstable to use the run package task within a DTS and use the Jobs instead to chain the DTS.
For portability reasons, I do not let the standard command string in the job, I replace it with the command line generated by DTSRUNUI so the job refers to the package name rather than the ID.
This makes easier the task to move jobs to another server using a script.
I also use a network alias rather than either Local or Machine name.
Example, in the SQL Server Client Network Utility, i create an alias i.e "Datamart" that point to the machine I want. i have the same alias in all machines. I use this alias in all packages, jobs and connections so they will allways resolve to the machine I want. For servers, it is the local machine, for dev boxes, I manipulate the alias so my dev instance will take data from the server I want.
Last but not least, I use DTS Backup 2000 to move DTS packages from server to server and i use the server's DNS name in the OLAP Cubes connections or Query connections so if I change Production Server, I simply swap the DNS entries and all user's queries now repoint to another machine without the user's knowledge.
Take care, Philippe
BI Guy
-
"The comment about registering the server as "Local" to ensure portability tweaks my interest. I'm wondering how you register a named instance as "Local"..."
By default a named instance can be referred to as " (local) ", if only one named instance of SQL Server exists on the box.
As for the author, it seems like this is a work-around for not clicking directly on the package name when choosing the child package. Maybe he didn't know you could do that?
On a similar note...
By default the "DTSRUNUI" generates something like:
DTSRun /S "(local)" /N "zTEST-DTSRun" /G "{32E787CD-4764-4D7A-820C-43888AE1F87C}" /A "Body":"8"="TestBody" /A "Subject":"8"="TESTSubject" /W "0" /E
This has both Name and PackageID specified. Name is portable, but PackageID is not. Removing PackageID from the command string fixes this problem, and does not affect the exection of the package.
Signature is NULL
-
great content. figures helped a lot. overall a very helpful article.
-
Very original article on an interesting topic, and also very well written.
-
Very good article, concise information and excellent presentation.
-
Our requirements were very clear:
- Make our DTS workflows available for CD distribution to new and existing clients
This eliminates the ActiveX variant suggested by another reviewer; we cannot ssume that ClientX or ClientY, Z, etc - will allow us to install and run our controls. It's the reality out there...
- Bring them in the DTS editor for running, no DTSRUN command line running.
- Allow modifications by the Cleint using the visual interface
- Make sure that any modifications at the client will not break package chain execution, as long as there is only one version present.
Cheers,
Gus
-
The name only doesn't work....
Our requirements were very clear:
- Make our DTS workflows available for CD distribution to new and existing clients
This eliminates the ActiveX variant suggested by another reviewer; we cannot ssume that ClientX or ClientY, Z, etc - will allow us to install and run our controls. It's the reality out there...
- Bring them in the DTS editor for running, no DTSRUN command line running.
- Allow modifications by the Cleint using the visual interface
- Make sure that any modifications at the client will not break package chain execution, as long as there is only one version present.
Cheers,
Gus
-
Try using your name only,
Our requirements were very clear:
- Make our DTS workflows available for CD distribution to new and existing clients
This eliminates the ActiveX variant suggested by another reviewer; we cannot ssume that ClientX or ClientY, Z, etc - will allow us to install and run our controls. It's the reality out there...
- Bring them in the DTS editor for running, no DTSRUN command line running.
- Allow modifications by the Cleint using the visual interface
- Make sure that any modifications at the client will not break package chain execution, as long as there is only one version present.
Cheers,
Gus
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply