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

 All Forums
 Managing Changes To SQL Server Code
 General SQL Change Management Discussions Forum
 Can dbghost work for us?
 New Topic  New Poll New Poll
 Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  


2 Posts

Posted - 12/05/2007 :  08:27:33  Show Profile Send bbakkebo a Private Message  Reply with Quote
Hello, I have evaluated most of the products on the market now as well as my company are using db scripting and comparison products already.
I have taken a look at your process and product and while I think your product is nice, I do not understand how it provides me any more than what I do today. I would like you to point out to me where dbghost does more than what I do now. I will point out to you below why I am here in the first place.

This is my companies process today.
1.Build the db script every night through our build server. So we always have the db scripted and versioned in Subversion.
2.Use a diff against our previous versioned database to get the differences in a script, nice and neat everynight with Cruise Control.
3.So now we have difference against our previous version. Now if there is major changes, then the diff fails and we now about it, but we have to manually look at it.--problem is here
4.Causes of those manually changes are mainly renaming of things or dropping of things, etc. So this is all manual process here, we have a process to handle changes, but it is all manual here: we have to write alter statements etc and include additional sql scripts to run, basically from what I see we have to do the same with dbghost. So this is where I would love to see something better.

Now I have pointed out my problem, I have reviewed your product as well as many others and none do what we want because it appears not to exist,which doesnt mean it couldnt bed created. Well, maybe there are a few solutions out there like team system, but the cost is out of my company's range.

We want to do what we are doing above, having database updates be checked upon a build update, scripting the differences
and if there are difference conflicts be able to have a tool that resolves those differencing conflicts, so if a table was renamed for example we could just set table a=b for example and the script would be generated and included back in. So if there was column name changes the same would happen.

If there were key changes this would be determined scripted, etc. What we are trying to do is take the away as much of the manual process as we can or at least make it simple for each developer. One thing that is an abosolute is the developers do not want to have to check out and check in code. What I was think is to capture changes from a plugin to ms sql server management studio, so things were automated right from inside there for each programmer. For example if you change a table name it is all scripted and stored back into the repository for you automatically. This actually would be nice.

Let me know your thoughts. Perhaps I missed something and dbghost already has the solution.

Google AdSense

Mountain View


125 Posts

Posted - 12/28/2007 :  06:08:28  Show Profile  Click to see leachm's MSN Messenger address Send leachm a Private Message  Reply with Quote

From your description of the main problem it seems that the "custom scripts" option in DB Ghost would let you at least capture the manual changes that are necessary in source control. This means that, rather than check out, manually fix and check back in the generated difference script you would create a "before" update script, check that in to source control and rerun the build to produce the correct delta script. It doesn't help with the need for manual changes to be made it is just better in terms of change management process.

Having a plug-in is a great idea as that would enable the tricky "rename" type changes to be captured and automatically written into the "before" script and it is on our feature list :)

The difficulty here is how to synchronise the check in of the changed scripts with the other code to which the overall change relates. For example, if you updated a C# class file and a stored procedure you would have to check in the sproc in MS and the class file in Visual Studio. This would break the atomicity of the change. I'm sure we can work something out for this but I'm just trying to illustrate that this may not be as simple as it first appears.

Lastly, though, if your developers have made it an "absolute" that they do not want to check out/check in code then that, in my opinion, is a big problem.

Developers need to be aware of, and follow, good change management principles - period. I regard adherence to good team working processes (as that is what good source control practice is) as much a part of a developer's job as writing code. I have had experience of "superstar" developers writing excellent code but completely destroying project morale and, ultimately, project delivery by not working as responsible team members.

I say this having spent 20 years as a developer working on projects both big and small: SQL code is no different from any other type of code when it comes to source control. You wanna change it? Check it out first.


Malcolm Leach
You must be logged in to see this link.
DB Ghost Build, Compare and Synchronize = Change Management for SQL Server

Edited by - leachm on 12/28/2007 06:14:22
Go to Top of Page


2 Posts

Posted - 01/08/2008 :  06:15:16  Show Profile Send bbakkebo a Private Message  Reply with Quote
Thanks Malcolm for your response. We had many discussions after I posted my message in December and now our developers agreed to update things manually.

We have now taken things a little further and developed a plug-in to sql server manager which does a lot of the manual steps for us. Thus, we will drive our db update process more or less semi-automated, but the code changes are still manually done by all developers, until someone comes up with a better solution we will run development this way.

It could also be ORM is the solution for the future, but for our size(5 developers) this seems to be the best option now.
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