Post reply

ssis

  • April 10, 2010 at 8:29 am

    #217730

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

    2)can we deployee a package using SSMS?

  • April 11, 2010 at 12:50 am

    #1149684

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

  • April 12, 2010 at 12:35 am

    #1149830

    [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

  • April 13, 2010 at 12:38 am

    #1150498

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

  • April 14, 2010 at 7:38 am

    #1151334

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

  • April 14, 2010 at 8:07 am

    #1151367

    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

  • April 15, 2010 at 1:57 am

    #1151940

    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.

  • April 16, 2010 at 4:35 am

    #1152675

    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.

  • April 16, 2010 at 12:46 pm

    #1153072

    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

  • April 16, 2010 at 5:32 pm

    #1153216

    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