April 12, 2010 at 1:17 am
I find the "File System" (which is backed up nightly) a convenient place to store packages. I can modify pacakges there easily and (OS) copy the entire package to a new server if need be.(say to create a stage version of a dev package).
So, what do the other options offer that is not supported by "File System"? For example, if our devs want to invoke an SSIS package programatically is it better\easier for them if I stored it in the msdb databse? (Don't ask me how they will invoke a package stored in there but that's another issue!)
TIA,
barkingdog
April 12, 2010 at 6:17 am
One disadvantage of the File System is that you have to handle security (authorization) yourself. Meaning, if your developer creates a job on the SQL Server but SQL Server Agent doesn't have the right permissions on the folder that stores your packages, the job will fail.
Browse these forums a bit, and you will find tons of topics that treat the same problem: "The package works fine in BIDS, but as soon as I put it in a job, it fails..." (which is usually a security problem) 🙂
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
April 12, 2010 at 9:55 am
Another security difference is that you can use the Integration Services roles in msdb to manage permissions on packages stored in SQL Server. They have no effect on packages stored in the file system.
Greg
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply