Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Automating DTS Execution Expand / Collapse
Author
Message
Posted Thursday, March 17, 2005 3:41 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, January 30, 2006 11:22 AM
Points: 10, Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/gcarnu/automatingdtsexecution.asp


Cheers,


Augustin Carnu



Post #168543
Posted Thursday, March 24, 2005 12:46 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, April 22, 2005 12:49 AM
Points: 1, Visits: 1

good article.

Thanks for the information supplied.

Post #169759
Posted Thursday, March 24, 2005 1:32 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, September 12, 2014 9:20 AM
Points: 50, Visits: 289

"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.

Post #169766
Posted Thursday, March 24, 2005 9:02 AM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 12:10 PM
Points: 49, Visits: 279

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
Post #169897
Posted Thursday, March 24, 2005 1:06 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, June 21, 2011 10:03 AM
Points: 577, Visits: 102

"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
Post #169965
Posted Sunday, March 27, 2005 9:35 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, March 27, 2005 9:32 AM
Points: 1, Visits: 1
great content. figures helped a lot. overall a very helpful article.
Post #170258
Posted Tuesday, March 29, 2005 5:54 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 29, 2005 5:48 PM
Points: 1, Visits: 1

Very original article on an interesting topic, and also very well written.

Post #170716
Posted Saturday, April 2, 2005 1:39 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, April 15, 2005 5:11 AM
Points: 1, Visits: 1
Very good article, concise information and excellent presentation. 
Post #171696
Posted Wednesday, April 6, 2005 12:17 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, January 30, 2006 11:22 AM
Points: 10, Visits: 1

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




Cheers,


Augustin Carnu



Post #172547
Posted Wednesday, April 6, 2005 12:18 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, January 30, 2006 11:22 AM
Points: 10, Visits: 1

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




Cheers,


Augustin Carnu



Post #172550
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse