Ah... sorry, Brad... I have to disagree with you on most of what you said except for "pushing a change to production without testing it first on a test server, should always be avoided".
First, I think that most DBA's that I know (and I know more than a hundred) do take the very risks that you speak of. The only thing they're not (and I'm not) willing to take a risk with is the safety of the data in a production database.
You want to upgrade a production box from 2005 to 2008 R2? Not a problem... build a parallel machine and work out all the bugs and faults first because experience tells me there's no such thing as a "transparent" migration. Then, do full regression testing of the apps because, sure as shootin', someone has embedded code somewhere and it can break during a rev change just like anything else (happend to us just about 3 months ago and our system DBA's had to migrate the data back to 2005.).
If you think all that's a bit cowardly, consider this... you know the risk of jumping out of an airplane with no parachute... so why don't you try it just based on someone's word or in the spirit of taking a risk? Heh... the answer, of course, is that you know better.
Same principle applies here... ;-) All good DBA's are secretly born in Missouri... the "Show Me" State. :-P
And, remember... they don't call it the "bleeding edge" for nothing.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs