New Zealand's new Copyright Law presumes 'Guilt Upon Accusation' and will Cut Off Internet Connections without a trial. CreativeFreedom.org.nz is against this unjust law - help us


A Space for All Things .NET Related


[dotnet] visual studio database projects in 2005 or 2008

By James Hippolite, in , posted: 23-May-2008 15:00

Ah!  You caught me out; yes, we primarily do single-developer projects.
  • Still, I find the Database Project useful not only as a source repository of migration scripts, but also:
  • The list of Database References helps keep the 3 environments handy when wanting to apply a script to any particular environment.
  • And, when you right-click a database object in the Server Explorer and click Generate Create Script to Project = very handy.
  

From: dotnet@dot.net.nz [mailto:dotnet@dot.net.nz] On Behalf Of Andrew Shearer
Sent: Thursday, 22 May 2008 4:03 p.m.
To: dotnet@dot.net.nz
Subject: [dotnet] RE: visual studio database projects in 2005 or 2008
 -->
Do you have a whole team working on this migration script, or just you?  
From: dotnet@dot.net.nz [mailto:dotnet@dot.net.nz] On Behalf Of James Hippolite
Sent: Thursday, 22 May 2008 3:51 p.m.
To: dotnet@dot.net.nz
Subject: [dotnet] RE: visual studio database projects in 2005 or 2008
 -->
I use Database Projects; here’s how:
  • Each week I create a new migration script e.g. Update20080523.sql.
  • All database changes made to DEV, are scripted and saved to this file.
  • I test and re-test it in DEV.  Obviously this requires some smarts around whether to attempt to recreate objects or update data (IF EXISTS…).
  • I apply it to TEST, usually only once.
  • Finally, during Friday’s change window, I apply it to PROD; definitely only once.
  • It helps to place a comment at the top of the file referencing the changed objects.
   

From: dotnet@dot.net.nz [mailto:dotnet@dot.net.nz] On Behalf Of Andrew Shearer
Sent: Thursday, 22 May 2008 3:31 p.m.
To: dotnet@dot.net.nz
Subject: [dotnet] visual studio database projects in 2005 or 2008
 -->
Who here actually uses these and finds them practical?? Sure, the source control aspect would be great but all i see is this hugely outweighed by trying to manage schema and data changes in a sequential fashion and the major problems that arise if that isn’t done correctly. We don’t roll out the entire database with each product release, but simply the iterative changes that have been made. Is that where we’re going wrong in terms of how a database project works? If you release just the incremental schema and data changes like we do, how are you maintaining this sequence in your database project ‘change scripts’? 

thanks



Other related posts:
That Awkward Moment
Geek Post Monthly Newsletter Volume 2 Issue 9
Geek Post Monthly Newsletter Volume 2 Issue 8






Add a comment

Please note: comments that are inappropriate or promotional in nature will be deleted. E-mail addresses are not displayed, but you must enter a valid e-mail address to confirm your comments.

Are you a registered Geekzone user? Login to have the fields below automatically filled in for you and to enable links in comments. If you have (or qualify to have) a Geekzone Blog then your comment will be automatically confirmed and shown in this blog post.

Your name:

Your e-mail:

Your webpage:

JamesHip's profile

James Hippolite
Wellington
New Zealand


Welcome to my technical blog. 

Here, I attempt to distill the Microsoft Certified Professional Developer knowledge I have accumulated since first qualifying MCP in 1996.  This blog started on 13 September 2007 as an off-shoot from my mixed up personal blog.  But it took a shot in the arm from Scott Hanselman's talk at TechEd New Zealand 08 "32 Ways To Make Your Blog Suck Less".