This is just one of those times when I have to wonder who’s calling the shots from a product perspective over at MS. I just started experimenting with Visual Studio Team System for Database Professionals and have run into an absolute show stopper that completely prevents me from being able to do anything useful with the product.
First off, I mentioned a while back the fact that “regular” DB projects in VS2005 were cripppled. I have no clue why Microsoft, who often goes so far out of their way to provide backwards compatibility, would have gone and trashed DB projects the way they did. It became somewhat clear when VSTS4DBP was announced that they were trying to actually create a “real” product around database development and I was happy because I figured this new support would include all the features that I lost and more. Well, as it turns out, with all the cool, new things that VSTS4DBP offers, they STILL don’t support DML/BCP in the product.
So, what does this mean exactly? It means that you’re basically left hanging, looking for your own home-brewed solution, for any “static” data you may have in your databases. Most likely that means executing bcp on the command line to export data from your tables, adding those files to your project manually and then adding some BULK INSERT statements into the Script.PostDeployment.sql file of the project.
Scary thing is, this was brought up and Microsoft has said that they consider it great feedback… for the next version of the product. Ridiculous, right? Please voice your opinions via this bug over on Microsoft Connect.
I’m not quite sure I get what you’re fussing about. TS4DBP (Team Data) is targeted toward developing and deploying databases. Just like TS4Devs is targeted toward developing and deploying applications.DML exercises your database. You can create Unit Tests that run against your DB in team data.BCP is for copying mass data from one data source to another. Why not use SQL Management Studio/Integration Services to do that?As I see it, Team Data and Management studio should remain separate because database development and database management are two separate activities.
Just had an aha moment…I see exactly what you’re saying and agree fully! We have a number of tables that need to be populated just so or our application throws a FIT.Heck a number of our SPs rely on those tables being populated.I guess for now that’s what the postdeployment script is for.Honestly, I think that it will take some time to properly adapt your environment to take maximum advantage of team data. Heck, we’re still going through some growing pains with Team Foundation and it’s been RTM for almost a year now. So I’m not quite disappointed that a pre-release tool isn’t exactly where we want it.