July 17, 2001 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/saveyourpackageslocally.asp
August 6, 2001 at 11:08 am
Just another note about DTS packages. When you move a package (call it A) from one server to another and A executes another package (call it B), the newly saved package (call it A_new and call its counterpart B_new) will try to execute B instead of B_new. To solve this, open A_new in design pane and go to the execute package task and re-select the package to execute. The package A_new's execute package task was still looking for B with the B's version GUID number instead of B_new.
August 6, 2001 at 12:02 pm
August 9, 2001 at 10:32 pm
Also, I like to have all my packages owned by the same owner. This is especially good if you are developing a system you are going to be selling. If everyone is creating packages under different logins, the only way to get them all owned by the same owner that I have found is to save them out as files and then have them opened and saved to the SQL Server by one login.
On another note - if you have some developers using the SQL2000 Enterprise Manager and the Server is SQL7, do not have them create packages and save them as files or on the Server, as you will not be able to work with them from the SQL7 Enterprise Manager on the server itself or from any other machine using the SQL7 GUI.
Mindy
August 10, 2001 at 7:56 am
You can get around the SQL 7 issue with a password, though you have to be aware of the differences in DTS tasks. Only some of the tasks are available in SQL 7.
Steve Jones
August 13, 2001 at 1:56 am
I was dissappointed that this article didn't touch on the sort of dramas I've experienced with moving DTS packages between servers.
Once you move a DTS package, you might have to change it references to server, database, tables or files, and if it notices anything is (temporarily) invalid, it wants to wipe out the transformations. You cannot edit invalid transformations to figure out what it is supposed to do and fix the real problem.
I thought that saving as Visual Basic (under SQL2000) offered more hope. At least then you have something you can look at if there are inconsistencies. Also, you can do global replace for things like database name.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply