Tom Van Harpen (8/20/2014)
Thanks for the response Phil.I am starting to see some benefits and after we get rolling I'm sure we'll find new and clever ways to use the environments.
Also I answered yes to all 3 questions.
The explanation on how the params stay linked even which switching environments was very helpful.
What concerns me is development. We do all development on separate computers using different instances of SQL Server for each developer and we utilize our own local paths for storing source files and such.
With the previous Package Configurations they would be applied when the package was being opened in BIDS so when I opened something on MY computer all the values would be pointing to my local resources because I setup these values in my local SQL Server configuration tables.
Now with SSDT if I start a project then another developer opens it they will need to manually change the parameters in the package so they can work against their own dev environment. Do you know of any way around this like some sort of local environment that is built in to SSDT? Of course we could all coordinate how we store things locally and always use (local) for SQL connections.
If this has all boiled down to the question of developers having different local instances of SQL Server, then I do have a solution for you.
1) Get every developer to create two new instance aliases (one 32-bit, one 64-bit) on their machine. The aliases should have the same name for all developers (both 32- and 64-bit) and should point to the local instance on that machine.
(Create the aliases in SQL Server Configuration Manager / SQL Native Client 11.0 Configuration (x2))
2) Modify your package connection strings to use the common alias name.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.