Tracking Database Schema Changes with DbPro

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss Content Posted by Jacob Sebastian » Tracking Database Schema Changes with DbPro

14 posts, Page 2 of 2

««1 2

Tracking Database Schema Changes with DbPro

Rate Topic

Display Mode

Topic Options

Author

Message

Grant Fritchey

Posted Thursday, July 26, 2007 11:16 AM

SSChampion

Group: General Forum Members
Last Login: Today @ 9:14 PM
Points: 13,381, Visits: 25,174

It sounds like you're almost using the tool backwards. We've been spending all our time working on the schema, in source control, and then we automate getting it out to databases. Once we started using this tool, no development was done on a database that we had to automate getting into source control. It's a paradigm shift, but you have to look at source control as your authoritative source of the database under development, not the database itself.

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software

Post #385521

Andras Belokosztolszki

Posted Friday, July 27, 2007 3:13 AM

Ten Centuries

Group: General Forum Members
Last Login: Thursday, January 26, 2012 5:26 AM
Points: 1,367, Visits: 1,585

Another tool that could help with your schema changes is SQL Compare Pro 6.0 by Red Gate (disclosure #1: I do work for Red Gate; disclosure #2: I'm the architect of the tool in question). It allows you to read in SQL files and compare them directly with another set of SQL files or with a live database. The nice thing is that it allows you to synchronize the changes in both of the directions, so you can update your live database as well as your script files to reflect the changes. Upgrading the scripts directly clearly has some limitations, I summarized these on Source Control and Databases. On the other hand, with this tool you can support both of the common development styles (and their mixtures), i.e. one where you maintain a set of creation scripts and execute them to get a db, and one in which you change the db directly, but want to update your SQL scripts in your source control.

Andras

Andras Belokosztolszki, MCPD, PhD
GoldenGate Software

Post #385711

yonision

Posted Sunday, July 29, 2007 4:46 AM

Valued Member

Group: General Forum Members
Last Login: Wednesday, April 03, 2013 11:39 AM
Points: 52, Visits: 151

This is a replay to the post above by Mark:

Mark, the tool that i have mentioned from Nob Hill Software (http://www.nobhillsoft.com/Randolph.aspx) does exactly that: automatically monitors your database, finds the changes, can notify you of all that's changed (via reports or even email) and pushes the changes into SourceSafe

Post #386135

Peter Schott

Posted Tuesday, August 21, 2007 4:55 PM

Right there with Babe

Group: General Forum Members
Last Login: Today @ 11:01 AM
Points: 739, Visits: 927

Mark,
If you're running SQL 2005, have you considered creating DDL triggers along with some form of Audit database? I did that on our Dev servers and it's been very useful to know who has created, altered, or dropped objects in the database. I even have some minor insight into the command(s) run. Now if everyone would stop using "sa" just because it has no password......

-Pete

Post #392658

« Prev Topic | Next Topic »

14 posts, Page 2 of 2

««1 2

Permissions