I required our group, from the beginning, to not store them in the database. That's very contrary to what most people do, but from my perspective it made them more "normal" in terms of source control. We leave them in the structured file format and store them in source safe, and deploy them much as we would any other executable. Then we invoke them with loading from file and/or dtsrun.

An issue we have not crossed but need to is how to search for dependencies, for example if we want to change column XYZ in table ABC how do we find where it is used, e.g. in TSQL steps in DTS. If you haven't tried, notice that the Unicode format (I think it is that) prevents a simple SEARCH find finding it.

What we think we might do is script a routine that will extract the equivilent VB code to a file in a parallel directory tree. This would not be checked in, but would simply be there for searching. Though arguably if you checked it in, you would have easy differences of DTS packages. My concern is that it would NOT get checked in all the time since it would not be automated (i.e. the steps to script and also check in would often not both occur simulataneously with checking in the DTS).

So far it has all worked well for us. It made the DTS packages more "normal" with regard to other pieces of code programmers were writing (all DTS packages for us are done by VB/C++/etc programmers so this fits their paradigm)