Since CTP 5 , I’ve been using DB Pro  (Visual Studio for Database Professionals, aka ‘Data Dude’) to manage an R&D micro-project that I have developed over time.

The DB Pro version of Visual Studio is in addition to the architect, developer, tester and project manager versions and fits in nicely into the whole of Team System.

Golden Rule : Project is master, not the Database…

I imagine that the transition into use of DB Pro is much easier for a developer rather than a DB administrator given that the DB Pro project, and not the Database itself is the master version of your database scripts.

By ‘scripts’, I do mean every single database object that the database itself contains/ will contain. Every table, SPROC, user, primary key , foreign key, index, etc… is represented in the DB Pro project as a seperate script. Any change to a script can be managed through TFS source control and DB Pro (& TFS Continuous Integration) will ‘Build’ your project and cause the build to fail if some invalid SQL has been written. Indeed, you cannot run-in any invalid SQL into the related database.

 So what is DB Pro trying to achieve….Is it biting off more than it can chew ?

Validating Scripts

As a developer , you are probably going to have to write a sql script at some stage of your life. It’s all good, that is until you meet the gatekeeper – that’s right , the DB Admin.

The DB Admin is your friend, but when you are up against the wall for a release and that last minute change had to be done to one of your scripts…the DB Admin may seem to become that extra few blocks that takes away your view over the wall.

So , you hand over the change to the middle man,it gets validated and when the DB admin is satisfied that , yes, the script can be pushed to production, you take a breath and the urgency wears away…

So what if both parties to this transaction can be joined implicitly into the one manageable process, the instrument to be used being DB Pro with TFS ?

Let’s review the above scenario…The issue was that the DB Admin is accountable for the safe release to production of the developer’s script. The developer must have any of the scripts written by him/her validated by the DB Admin to ensure that the database, as a whole does not become unstable/corrupted by these script(s).

DB Pro takes over the DB Admin’s role in this scenario…

DB Admin – A dying breed ?

Eh, no…DB Pro does not replace the DB Administrator, it simply provides a single , managed, environment where both developer and administrator can work on the same source and produce a union of the work as a labelled release from TFS.

The database and related DB Pro project(s) will need a (number of) DB Admins to implement any data conversions, security policies, etc…but the validation of scripts can now shift to the use of DB Pro (with TFS).

Using DB Pro with TFS, the developer can be sure that last minute script is correct, given that the latest version of the project including this script builds successfully. So, you check-in your script to TFS, label the latest version and the latest release will be ready for deployment.

Conclusion

DB Pro is defining the grey area that seperates the developer and the DB administrator through providing a single point of interaction that manages the basic functions common to both the developer and DB administrator, namely the management of database scripts.

Part 2 of this series will take an in-depth look at the functionality available in DB Pro and will be added to this blog in due course.

[tags].Net, Visual Studio, DB Pro, Data Dude,Team Foundation Server[/tags]

~ Alan Crowley ~