Deploying SSIS pkgs

Hi,

I have some questions.

Regarding SQL Server deployment, it says to use this option if sharing packages between servers. Does this mean sharing packages between development, test, and production environments? Or just sharing among production servers?

That is, I am trying to determine if I should deploy my packages on SQL Server, or just store them on the local file system. These packages will NOT be used on any other production server. So should I just keep them on the file system?

Another question. I see that I have a package stored in the "sysdtspackages90" table in the msdb database. Since I have not done any SQL Server deployment yet, I don't understand how this particular package ended up in this table. Is it OK to remove? I think this is a previous version of a package that I have since re-written. Are there any dependencies on this "sysdtspackages90" table that I should be aware of?

Thanks!

Sharing between servers, in this case, refers to sharing between production servers. So you're probably fine sticking with the file system.

Not 100% sure about dependencies on the sysdtspackages90, but if you remove it by connecting to the Integration Service in SSMS, it should be fine.

|||

Thanks for your reply!

Is there any advantage whatsoever for deploying to SQL Server if you are not sharing packages?

Also, where do I delete the package stored in the "syspackages90" (or whatever it's called) table... I have another package by the very same name stored in the file system. But I don't think they are the same package. Is that possible?

|||

Opinion varies - personally I prefer the file system, because I find it easier to deploy there.

To delete the package, connect SSMS to the Integration Services on the server you are working on. It's one of the Server Type options when you choose File..Connect Object Explorer. You should be able to browse to the package from there.

|||As John indicates, opinions do vary. I for one love deploying to MSDB because I get to use SQL Server roles and security to control access to my packages and in my packages. So once I set up a user account in a connection inside of a package, I don't have to worry about SSIS stripping the password off of that connection when I deploy. A nice feature, I should say, and probably the method that was envisioned as being "standard." (I don't know that for sure, it's just a guess, what with all of the integration that MS tries to achieve.)|||

Thank you for your reply. Yes, that makes sense.

However, I am a little nervous about deploying to SQL Server - for one, I've never done it. Are there any caveats I need to be aware of? For example, what if I need to change something? Do I need to "re-deploy" if any of the packages change? Or are the changes saved to SQL Server automatically when changes to the packages are saved?

Also, what is this "magic folder" (the folder where dependent files go) Is there a "standard" place for this folder? My book on SSIS mentions it, but does not indicate where to put it.

One more thing, I am clueless about configuration files. Are these important? I realize this is a vague question. But the packages I am working on now are tested and working... they are not going to be migrated anywhere. So should I bother with a configuration file? That is, when would I need a configuration file?

Thanks much!

|||I will try this, thanks