Save Your Packages Locally

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714297

  • epurg

    SSC Rookie

    Points: 35

    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.

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714297

    Thanks for the tip.

    Steve

    Steve Jones

    steve@dkranch.net

  • mcurnutt

    Ten Centuries

    Points: 1222

    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

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714297

    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

    steve@dkranch.net

  • Clay_G

    Default port

    Points: 1454

    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 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply