Visual Studio Database Edition: A few newbie questions

Question

Hi folks,

I'm looking at adding Visual Studio Database Edition (aka. VSDE) to my version of VS2008.

Q1. What's the order of install of these products? is this ok?

Update: Fixed the ordering of the install, based on feedback.

• VS2008 (c# [no sub options], web dev, ts tools. nothing else).
• Team Foundation Client (found on our msdn dvd)
• VSDE
• VSDE GDR (I think we downloaded this from download.microsoft.com)
• VS2008 SP1
• VS2008 SP1
• VSDE GDR

Q2. Is it 'acceptable' to not have sql server installed on the client machines but use a dev box? what about private instances of their dev data? Basically, we don't install sql on our vista dev boxes. I personally don't like having extra services which i might not use all the time. We have 3 DB's usually - Dev, Test, Production. Should we make multiple Sql instances on our dev box (for example) which could be SqlMachine\User1, SqlMachine\User2, etc.. and the root SqlMachine is 'Dev'. This way, we can each use VSDE to play with our own db instance and this then goes up to the Dev instance?

(i hope that made sense).

cheers!

Answer 1

Q1 - the GDR has a pre-requisite of VS2008 SP1, so switch those last two around.

Q2 - I believe that each dev should be working with their own sandboxed database instance, yes. If you don't want to install instances of SQL Server on your workstations, then using multiple instances of SQL on a development server sounds like a reasonable solution.

Answer 2

I would put the DB on the development machine. You can change the service so that it doesn't start by default and start it manually whenever you want to use it, if you don't want it running all the time. I prefer this so that I'm not dependent on the availability of another system while developing. If you go this way and want something other than the Express edition included in VS, install SQLServer (I use the Developer Edition) before installing VS so as not to get the Express edition installed by default.

Answer 3

The installation order looks fine to me now that you've made your fix.

With respect to a local database: I would recommend having a local copy for a number of reasons. First, you'll certainly need to test against a database and a local copy is quite convenient - especially if the Dev database is ever down. Second and more importantly, if you are also producing database code (stored procedures or DDL to alter the database) you'll want to have a private sandbox to get things right before you merge it with the copy shared by others (note that I am assuming that you have rights or responsibilities for changing or adding to the database structure or sprocs).

It is a challenge in many database-centric environments is to keep a history of your changes because, in many projects, the database structure itself isn't kept in source control. I get around that by keeping one or more SQL DDL files in the app_data directory of my Solution (ASP.NET). Since the entire solution is under source control, I have a record of the changes I make as I move the product along from the current point release to the next (obviously but very importantly, this is removed before we go live). When you integrate your code with the rest of the team, of course, you will have to do a careful code review of any structural changes you are suggesting before you modify the Dev server. Daily builds/integration will help to keep this from getting out of hand.