Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase ««12

Tracking Database Schema Changes with DbPro Expand / Collapse
Posted Thursday, July 26, 2007 11:16 AM



Group: General Forum Members
Last Login: Today @ 3:45 AM
Points: 17,172, Visits: 32,133
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 Query Performance Tuning
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #385521
Posted Friday, July 27, 2007 3:13 AM

Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen 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 Belokosztolszki, MCPD, PhD
GoldenGate Software
Post #385711
Posted Sunday, July 29, 2007 4:46 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, January 20, 2016 1:40 PM
Points: 55, Visits: 164

This is a replay to the post above by Mark:

Mark, the tool that i have mentioned from Nob Hill Software ( 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
Posted Tuesday, August 21, 2007 4:55 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, November 29, 2016 1:00 PM
Points: 991, Visits: 1,900
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......


Post #392658
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse