The Original .NET Geek

Database Management
VSTE for DB Pros operates with the assumption that the project is the database source.  That means that all the files in the project represent objects in the database.  If you want to make a change, you would make a change to the file in the database project and when you build you would point it against the target and generate a diff script to update the target data source.  Script generation will discussed more in the Deployment section.. 

Refactoring
The tool makes an effort at providing refactoring and that is a good thing but frankly, it is limited in its functionality.  The one feature that CTP 3 does have is 'Rename'.  Choosing rename will take an object and do a rename on that object.  Since the project has a dependency graph of all the objects, it does a good job of finding all dependencies and showing you in the standard refactoring interface what items will change.  You can see what changes are about to happen and cancel if you wish.  This is where this feature stops. 

What it does not do is try to find other references or rename any comments.  So lets say that I have other projects loaded in the solution and I reference a stored proc in the database project.  The rename won't even pretend to rename the stored proc. It also makes no attempt at renaming comments I may have made in a script file.  I am not to sure why the team decided to go this way.  I can only speculate that they did not wish to rename anything that they were not sure was actually a reference to the object.  The problem with this is that now, I have to manually go and do a find and replace.  My one easy 'refactoring' has now become a bit more complicated.  What they could have done is to show 'candidates' for a rename similar to the way a 'Rename' in app code does BUT they could have made the default be unchecked for objects that it was doing a 'dumb' (my term) rename on.  This way their tool is making me more productive by saving me some key strokes and some mouse clicks.

It would also be cool if they would have made it easy to add my own re-factorings.  Maybe even given some guidance on how to do it (similar to Code Rush).  In fact Code Rush is what I am playing with now to do my own re-factorings.  More on that later.  Any how the refactoring features need some work.

Unit Testing
Well first there was T-SQL Unit but now you can handle your unit test within your project.  It works similar to the way a regular unit test project works.  Once the unit test project is loaded you can create a new unit test and what loads is a file that has a simple designer that helps to write the unit test code.  Out of the box you can test for a predefined set of conditions but you can switch to the code view and get as fancy as you would like to test the database.  All in all a cool feature.  I will probably use this just because I can use the built in testing framework that VSTS provides.

Deployment
Well this is one of the feature sets that will make or break the product.  Right now it is not 100% there in my opinion.  First the good things.  Deployment has become pretty simple with the same metaphors that are used with all other VSTE products.  VSTE for DB Pros has a New and Update build configuration.  Each of those will generate the script needed to update a target database. 

Next the downer(s).  There is currently no option to generate a build script against another version of a project.  This will be an issue that if not taken care will seriously limit the product.  

Schema Compare
Schema compare is one of the tool's big features.  That being said, it is not 100% there yet.  The tool works by pointing it to two databases or a project and a database (note that there is no Project to Project comparison).  The schema comparison will show you the differences and allow you to generate script that would get the destination sync'd up with the source.  There is even a preview window that shows you the script so you can copy and past that else where.  The script that it generates is much more robust (error handling and transaction mgmt) than the deploy script that gets generated with a build.  That is extremely odd to me since I would want error handling and transaction management in the deploy script as well. 

The way that scripts are generated is a bit of a mystery to me which brings me to my next gripe.  Since the objects in the project are represented by an internal object model, I would think it would be easy to generate the dif and deploy scripts based on a template.  This would allow me and any other organisation to customize the scripts by adding robust error handling or transaction management by object or object family.

Data Compare
Again like schema compare you can point to two tables and sync target tables.  I did not see any means of getting the script out of the tool though which is a downer.  i would like to be able to use it to incorporate it as part of the build so once the database is sync'd I can run the data script to update it.  Kind of a bummer.  Hopefully it will be exposed by V1.