April 5, 2012 at 9:19 am
Grant Fritchey (4/5/2012)
Any time you want to see the warts & all presentation, come watch mine. I don't hold back. We have a ton of advantages over Visual Studio. They have a ton of advantages over us. Both tools are functional, and that's the important part.
For example, one advantage in Visual Studio is the ability to have pre/post deployment scripts. SQL Source Control doesn't support that kind of thing... yet. So we're not perfect, not even close. We're just striving to do a good job and get better.
Grant,
When are you doing your next presentation? Unfortunately, I missed some of your other online ones in the past do to scheduling conflicts. I would be interested in the advantages & disadvantages you have found in both. The company I just started at is going to be evaluating both products to improve the development practices here.
John
April 5, 2012 at 9:21 am
Eric M Russell (4/5/2012)
I use TFS, but up until about three years ago, I was still using Visual Source Safe 6.0. It was good enough for versioned source control, which is why it has persisted for so long. It's what, 15 years old now?
I thought VSS was fine for me. I just need check in, check out, and branching. Seemed to work well, but we didn't do any merges or strange things.
Today I'd use SVN since it seems simpler to me, it's free, and it's dirt simple to implement.
April 5, 2012 at 9:22 am
Steve Jones - SSC Editor (4/5/2012)
Eric M Russell (4/5/2012)
I use TFS, but up until about three years ago, I was still using Visual Source Safe 6.0. It was good enough for versioned source control, which is why it has persisted for so long. It's what, 15 years old now?I thought VSS was fine for me. I just need check in, check out, and branching. Seemed to work well, but we didn't do any merges or strange things.
Today I'd use SVN since it seems simpler to me, it's free, and it's dirt simple to implement.
Try branching in VSS... <shudder>
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 5, 2012 at 9:24 am
John Dempsey (4/5/2012)
Grant Fritchey (4/5/2012)
Any time you want to see the warts & all presentation, come watch mine. I don't hold back. We have a ton of advantages over Visual Studio. They have a ton of advantages over us. Both tools are functional, and that's the important part.
For example, one advantage in Visual Studio is the ability to have pre/post deployment scripts. SQL Source Control doesn't support that kind of thing... yet. So we're not perfect, not even close. We're just striving to do a good job and get better.
Grant,
When are you doing your next presentation? Unfortunately, I missed some of your other online ones in the past do to scheduling conflicts. I would be interested in the advantages & disadvantages you have found in both. The company I just started at is going to be evaluating both products to improve the development practices here.
John
No online ones coming up. SQL Saturday in Atlanta a week from Saturday... Um... Rally in Dallas, SQL Saturday in Rochester. Those are the best opportunities I have between now & May. I'll be covering Red Gate at all those and at one or two (not sure which) I'll be doing the session that Steve talked about in the editorial. Sorry it's not more. My wife likes having me around the house for some reason.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 5, 2012 at 9:49 am
I've used Visual studio Developer Edition 2010 to deploy database changes and find that as it maintains a project 'schema' that is compared with the schema of the current database and the differences applied. Coupled with features that ensure that no changes are applied that could lose data, I have found it to be very reliable particularly when deploying against multiple customers etc. Have found that you may have to do pre deploy scripts for the odd task but overall definitely moves things on from delta scripts etc..
April 5, 2012 at 12:21 pm
Any time you want to see the warts & all presentation, come watch mine. I don't hold back. We have a ton of advantages over Visual Studio. They have a ton of advantages over us. Both tools are functional, and that's the important part.
For example, one advantage in Visual Studio is the ability to have pre/post deployment scripts. SQL Source Control doesn't support that kind of thing... yet. So we're not perfect, not even close. We're just striving to do a good job and get better.
Grant,
Ok that's understandable, but I am just curious what kind of dollars is SQLServerCentral getting from Redgate to advertise their products on their site? Or do you know? 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
April 5, 2012 at 12:29 pm
TravisDBA (4/5/2012)
Any time you want to see the warts & all presentation, come watch mine. I don't hold back. We have a ton of advantages over Visual Studio. They have a ton of advantages over us. Both tools are functional, and that's the important part.
For example, one advantage in Visual Studio is the ability to have pre/post deployment scripts. SQL Source Control doesn't support that kind of thing... yet. So we're not perfect, not even close. We're just striving to do a good job and get better.
Grant,
Ok that's understandable, but I am just curious what kind of dollars is SQLServerCentral getting from Redgate to advertise their products on their site? Or do you know? 😀
Not a clue.
You do know they're the same company, right? SSC is owned by Red Gate. Says so right at the top of the page on the right: "A Community Service from Red Gate"
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 5, 2012 at 12:32 pm
Grant Fritchey (4/5/2012)
You do know they're the same company, right? SSC is owned by Red Gate. Says so right at the top of the page on the right: "A Community Service from Red Gate"
Well, it *would*, if it wasn't covered by the "corner peel"... 😉
April 5, 2012 at 12:41 pm
TravisDBA (4/5/2012)
Any time you want to see the warts & all presentation, come watch mine. I don't hold back. We have a ton of advantages over Visual Studio. They have a ton of advantages over us. Both tools are functional, and that's the important part.
For example, one advantage in Visual Studio is the ability to have pre/post deployment scripts. SQL Source Control doesn't support that kind of thing... yet. So we're not perfect, not even close. We're just striving to do a good job and get better.
Grant,
Ok that's understandable, but I am just curious what kind of dollars is SQLServerCentral getting from Redgate to advertise their products on their site? Or do you know? 😀
I don't think Steve has posted his salary publically. Nor would I expect him to. He's a RedGate employee, this is a RedGate site. They're not "affiliated" or "paying for ad space" - RedGate owns it outright, and says so right on the page.
On the point of negative data about RedGate products being missing from SSC: take it however you like to. I've posted comparisons between some of the RedGate products and their ApexSQL competition. In some cases, ApexSQL's tools had what I considered better features. But, as a point of comparison, I have a lifetime free upgrades license from ApexSQL that includes all of their main products, but I buy the RedGate tools instead because I like them enough better to cough up cash on it.
And I'm not a RedGate employee, not paid by them (unless you count the $75 they've paid for my SSC articles a few years back), and not in any way beholden to them.
On the converse of that, I use Confio Ignite, and am looking into Quest's Spotlight/Foglight/Performance Monitor, instead of RedGate's SQL Monitor, for performance bottleneck monitoring. I like the features and interfaces of the other two better. I have a license for the RedGate tool (in my ToolBelt license), but I don't use it and pay for other tools instead because of personal preferences.
I've also had some problems with RedGate's SQL Backup tool, and don't use that any more. Haven't found a competitor that offers something I do like, so I'm just using native SQL Server backups currently.
Does that help?
- 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
April 5, 2012 at 12:43 pm
ROLMFAO 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
April 5, 2012 at 1:00 pm
Grant Fritchey (4/5/2012)
No online ones coming up. SQL Saturday in Atlanta a week from Saturday... Um... Rally in Dallas, SQL Saturday in Rochester. Those are the best opportunities I have between now & May. I'll be covering Red Gate at all those and at one or two (not sure which) I'll be doing the session that Steve talked about in the editorial. Sorry it's not more. My wife likes having me around the house for some reason.
Looking forward to seeing you here in Atlanta at SQL Saturday.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 5, 2012 at 8:26 pm
Just a few months back, we were caught in such a scenario. We had a version in client's test environment, the client had already asked for a few major changes and we had implemented it when the clients wanted a few changes in the version they had on their test, but they did not want the requested major changes just yet.
We use Visual Source Safe, and had put labels on the code, so fetching the code was a piece of cake. But database is where we got stuck. At that moment, we were wishing we had done something about it!
But I still don't know how to do this with VSS and SQL Server 2005? Can someone point at the right direction?
April 5, 2012 at 10:35 pm
binak_86 (4/5/2012)
Just a few months back, we were caught in such a scenario. We had a version in client's test environment, the client had already asked for a few major changes and we had implemented it when the clients wanted a few changes in the version they had on their test, but they did not want the requested major changes just yet.We use Visual Source Safe, and had put labels on the code, so fetching the code was a piece of cake. But database is where we got stuck. At that moment, we were wishing we had done something about it!
But I still don't know how to do this with VSS and SQL Server 2005? Can someone point at the right direction?
What I might do is make a branch, linked in VSS, of the code you want to release later. The link will allow changes made in the main branch to be included, but you can track the objects as a group.
April 6, 2012 at 12:11 am
I am all for the concept of versioning. However, after reading through this, I find noone's addressed a few key issues that I have with traditional software versioning. If I missed it, I'm sorry...
In traditional software, if you need to go back to a different version, you simply build that version (label, whatever you want to call it) and drop it into the install. Poof, you're good to go.
In databases you need to rollback your production structure so you don't have data loss. You can't simply rebuild the database and port the data, at least not on large systems. Even then, if you had multiple minute schema changes, you're going to be adjusting for each and every one of them.
Thus, you need to include rollforward/back scripts with every label/version. This lends itself heavily to the delta model, particularly since one of the concepts is not just documentation, but reversal of rollouts that failed worse then the bug they tried to fix.
Now, in theory, you could use the creation model, build off a model and do a SQL Compare or similar to build your rollback script, thus saving yourself that headache. However, getting your company to spring for the tools you need can be a royal pain some places.
The other model I've seen is a continuous integration model... For databases, the less said about this the better. Once you've altered an index it alters/rebuilds every time you take that component out for the next build/release.
So between the three, Delta/CI/Creationist, I usually prefer Delta. It lends more freedom to independent component rolls, however you must document any dependencies both consistently and heavily.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
April 6, 2012 at 3:26 am
Not to mention some changes in delta scripts are irreversible (or very difficult/costly to make them), which in fact favors a snapshot methodology. You could with every revision copy the database, empty all entities that are not part of the "code/runtime state" and then make a snapshot. Or keep a parallel database that is stripped of the runtime state and apply the delta script in parallel there, so the process of removing the production data does not need to take place.
I would still choose to use delta scripts for the updates and store those alongside the snapshots. Then you can always revert to an earlier version by means of a snapshot and use the delta scripts to see in detail what was changed and how or roll forward revision by revision.
Viewing 15 posts - 31 through 45 (of 48 total)
You must be logged in to reply to this topic. Login to reply