Database Change Management
Database Change Management
Home | Profile | Register | Active Topics | Active Polls | Members | Private Messages | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?




 All Forums
 Managing Changes To SQL Server Code
 General SQL Change Management Discussions Forum
 Differences in DB development process
 New Topic  New Poll New Poll
 Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

TuanMinhChau


3 Posts

Posted - 11/08/2006 :  05:31:57  Show Profile Send TuanMinhChau a Private Message  Reply with Quote
Hi,

I've (briefly) evaluated Embarcadero's RapidSQL and also plan to also look at your DBGhost. Can you tell me how your database development processes differ?

Can you explain your website quote about being the "only true database change manager for SQL Server". What specifically do you mean by "true"?

Thanks.

Tuan Minh Chau

Google AdSense

USA
Mountain View


leachm



125 Posts

Posted - 11/11/2006 :  04:45:22  Show Profile  Click to see leachm's MSN Messenger address Send leachm a Private Message  Reply with Quote
The reason we believe that the "DB Ghost Process" is the only true database change management process is that the process regards the "source database" as a set of object creation scripts that reside in a source control system. You build a new database from these scripts (thus ensuring nothing is broken) and then use it as the source for a compare and upgrade of a target database.

Other vendors claim that "snapshots" give you change/version management but they simply do not provide an audit trail of changes - all they can tell you is WHAT has changed between two snapshots. The critical information of "who", "when" and "why" is simply not contained within snapshots and thus they are not "change management".

Imagine if we treated other code assets in this way! i.e. you have your source code on a network drive that everyone can change however they want to with absolutely no audit trail and then, every so often, you take a copy and try to compile and run it - a recipe for disaster, I'm sure you'll agree.

Yet we still continue to treat databases like this - compare and sync tools alone only provide a sticking plaster solution as all they do is take the legwork out of creating a delta script. They do not help in determining *what* schema changes need to be promoted and this has to be done manually by whomever is deploying changes.

This is why we are the only true database change management solution.

regards,

Malcolm Leach
You must be logged in to see this link.
DB Ghost Build, Compare and Synchronize = Change Management for SQL Server
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  New Poll New Poll
 Reply to Topic
 Printer Friendly
Jump To:
Database Change Management © Copyright 2005 Innovartis Ltd. Go To Top Of Page
Snitz Forums 2000
RSS Feed 1 RSS Feed 2
Powered by ForumCo 2000-2008
TOS - AUP - URA - Privacy Policy
ForumCo Free Blogs and Galleries
Signup for a free forum or Go Banner Free