On 7/18/07, Kris Jones <[EMAIL PROTECTED]> wrote: > The data is quite volatile. The schema typically has some changes > during each release cycle. We currently point at shared DBs, which I'm > thinking is the direction we'll stick with. But we are talking about > all of the suggestions mentioned here. I can see the benefit in having > local DB as well--in fact this is how I've developed in the past, and > understand how easily this scenario can break the app for other > developers (who may not be in a position to update their local > code-base for whatever reason).
What it seems to sound like is that the database differences need to be managed somewhat like the code -- with the capability to branch/merge/etc. There are ways to set that up, ranging from db scripts to storing the appropriate version of the actual database (in this case, a .BAK file perhaps) in the source control system. For example, using SVN, you can define an external link from a particular codebase to a particular branch or even revision of the database repository/tree/branch and lock the two (code and data) together. Add a generic osql load script to load the db into your local MSSQL and you're set (though a naming convention probably helps keep running the multiple versions in check) -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:284016 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
