May 4, 2011 at 11:36 am
Version control for application code (VB, CSharp, etc) I know. But version control for SQL, not really sure how to approach it, much less what to use for it. I know about SQL Source Control from Red Gate. But I'm wondering if there are any alternatives to that.
Also, I use Mercurial for my code versioning. Is it appropriate for SQL as well? How do you version control your SQL? Sorry if the question is vague, but I'm not sure where to start.
May 4, 2011 at 11:49 am
You can tell Management Studio to connect to Visual Source Safe or Team Foundation Server, so I think you can connect it to other forms of source control. Check your Options menus.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 4, 2011 at 11:52 am
You can connect visual studio to mercurial / svn
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 4, 2011 at 1:19 pm
VisualHg works with VS 2008 but not SSMS 2005 🙁
May 5, 2011 at 1:22 pm
I guess not many people version control their SQL....
May 5, 2011 at 2:17 pm
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
May 5, 2011 at 2:22 pm
Yep.
cgrammont (5/4/2011)
Version control for application code (VB, CSharp, etc) I know. But version control for SQL, not really sure how to approach it, much less what to use for it. I know about SQL Source Control from Red Gate. But I'm wondering if there are any alternatives to that.Also, I use Mercurial for my code versioning. Is it appropriate for SQL as well? How do you version control your SQL? Sorry if the question is vague, but I'm not sure where to start.
May 5, 2011 at 2:32 pm
On the cheap, you can look here: http://www.sqlservercentral.com/articles/System+Development+Life+Cycle/vcspart1/523/
Red Gate's Source Control supports a lot of VCS systems with the latest release and integrates nicely with SSMS.
Disclosure: I work for Red Gate.
May 5, 2011 at 3:05 pm
By any chance, have you written Parts 2 - 4? Good article by the way.
May 5, 2011 at 3:35 pm
Doh! my links are broken. Here you go
http://www.sqlservercentral.com/articles/524/
May 5, 2011 at 9:27 pm
cgrammont (5/5/2011)
Yep.cgrammont (5/4/2011)
Version control for application code (VB, CSharp, etc) I know. But version control for SQL, not really sure how to approach it, much less what to use for it. I know about SQL Source Control from Red Gate. But I'm wondering if there are any alternatives to that.Also, I use Mercurial for my code versioning. Is it appropriate for SQL as well? How do you version control your SQL? Sorry if the question is vague, but I'm not sure where to start.
Whoops, didn't see that line. Sorry...
FYI, this is what we are going with as we implement source control of our database.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
May 6, 2011 at 8:13 am
Our approach is "unique" to some degree. We house the majority of our T-SQL in Excel spreadsheets (Excel can be used for formatting and code generation). We use Jedi VCS for version control. We have macros that create formatted scripts which are stored in Jedi like any other source code. The spreadsheets are stored there too. Excel we have and Jedi is free.
There is absolutely no integration with SSMS. The power to work this relies solely on the skill and discipline of my developers. I have found over the years no substitute for developers who are disciplined and proficient. That is what keeps costs down and quality high.
Whatever system you use will work if you work it with diligence.
🙂
May 6, 2011 at 8:19 am
ItsJustMe_Peter (5/6/2011)
Excel we have and Jedi is free.
sidenote: That was very Yoda-like 🙂
That's interesting. I would have never thought of using Excel for code or code generation (outside of VBA). Thank you very much for the insight.
May 6, 2011 at 8:23 am
We develop our databases like our code with everything scripted to build the database is in source control. We have a task in our build process that builds an empty database template with every build of the application.
We have a version number stored in the database template that matches the version number of the application assemblies.
A post build step in our build takes the db templates and uses Red Gate SQL Compare and SQL Data compare(via custom code using RedGate's API) to script out the differences between database template versions. The scripts is also uploaded to source control.
Our installation package is built to include all the upgrade scripts and we have an step in the install where we apply all script changes to the database.
All of this is automated so that there is just a scheduled task that we run nightly when in a development cycle that generates an install package that can be run as a new install or as an update that will update the application and the database.
Occasionally there are issues with the database scripts where the auto generated scripts don't work and we have to manually go in an fix the update scripts by hand but I've been surprised in how infrequent that has actually been.
May 6, 2011 at 8:36 am
ItsJustMe_Peter (5/6/2011)
There is absolutely no integration with SSMS. The power to work this relies solely on the skill and discipline of my developers. I have found over the years no substitute for developers who are disciplined and proficient. That is what keeps costs down and quality high.
Whatever system you use will work if you work it with diligence.
🙂
Excellent quote. I have never had issues with SSMS/EM and developers because I have enforced the discipline administratively. All developers were trained to check out, file | open, edit, save, compile, check in.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply