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"?
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 www.innovartis.co.uk DB Ghost Build, Compare and Synchronize = Change Management for SQL Server
Differences in DB development process
Posted - 11/08/2006 : 05:31:57
