I would add that you want your scripts to be fully independent. By this, I mean you want to be able to run the script as many times as needed, on whatever environment you're running (local dev, staging server, production server, etc.). I know when I don't do this, I often overlook errors in my SQL script because my schema is already in place. To this end, you'll want to check for table/column/trigger/etc, drop it if it exists, then create it. This is a bit overkill perhaps, but it'll help you flesh out problems with your schema designs and scripts (reliance on specific ID's for example). A well written script can be run an infinite number of times without breaking the app (data changes notwithstanding, of course - but even this should be caught if you have proper relationship constraints).
You haven't lived until you've dropped a default value constraint in SQL Server without hard-coding (they are given random names when you create a column default, and you can't drop a column until you drop the constraint) Billy Cravens On Wed, Apr 13, 2011 at 4:17 PM, Mark Davis <[email protected]> wrote: > Hey guys, > > > > I am looking at adding database objects/scripts to subversion and just > starting from scratch. My entire development team works remotely, and > each time someone has a new db script for a task they are working on, it > typically gets emailed around so we can all update our local environments. > No real way to track changes. > > > > Anyone save db scripts in subversion and if so, have you run into any > gotchas? > > > > Thanks > > > > Mark > > -- > You received this message because you are subscribed to the "Houston > ColdFusion Users' Group" discussion list. > To unsubscribe, send email to [email protected] > For more options, visit http://groups.google.com/group/houcfug?hl=en -- You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en
