ssis

  • 1)how to deployee a package other than deployment utility in ssis

    2)can we deployee a package using SSMS?

  • I would deploy to the file system - than you can just copy the file to the server it needs to be deployed to.

  • [font="Verdana"]more information u ll get here on waht Dixon has suggested.

    http://msdn.microsoft.com/en-us/library/ms140117.aspx

    --Mahesh

    [/font]

    MH-09-AM-8694

  • Connect to integration services via Managment Studio, and over MSDB database right button - import package and configure the options.

  • From Visual Studio you can 'save a copy' of the package to the SSIS repository on the server. I don't know if this is a good way to do it, but its really easy. Just make sure you get the name right when you need to update it as it defaults to 'package'.

  • You can deploy using the DTUtil.exe program.

    Also, I STRONGLY recommend that you group the packages into directories, even if stored in MSDB. Otherwise you end up with a list of packages and don't know what they belong to. Just like DTS..

    CEWII

  • I think I tried the deployment utility once and gave up. We just use SSMS to set up folders in msdb and then "Save a copy of package as..." to the appropriate SQL Server and set Use server security to keep things simple. Packages are then usually run from SQL Agent jobs.

  • Out of interest: when working with packages in MSDB, is there any easier way of editing a package than having to export the package to DTSX?

    I was suprised when I could not edit a package directly in MSDB.

  • No there isn't.

    But I would make this point. Good code control requires that msdb be where deployed code goes not where it is edited directly. What I mean by that is that the sourcecode of the package should be in a source control system like TFS, VSS, or SVN. That you edit it there and then deploy it. We got into bad habits with DTS.

    This code control point is also valid for ALL other sql objects.. Tables, views, sprocs, triggers, etc.

    If we are editing the objects directly on the server we lose the ability to go back to a previously working version and also what happens when the database gets corrupted..

    I hate losing good code.. I make sure it doesn't happen..

    CEWII

  • That makes sense - msdb is the repository for the code that is run in test/production, and is not an area that allows you to edit. Makes good sense when considered that way.

Viewing 10 posts - 1 through 9 (of 9 total)

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