Comment On Practice Makes Perfect

First, and those people should be shot.

This is absolutely crazy... a manager with admin access to those servers, and he wasn't even *aware* a whole six-month project was running in order to upgrade them?!?

WTF!

God bless the PHB

a manager who had the foggiest clue on how to go about upgrading db servers? you must be kidding

And why would this manager even have the required access level?

Sounds like one of those magic people that, even though he assuredly attended all the planning meetings, still had no clue what was going on around him.

Oh, how wonderful it must be to be an oblivious manager. You have no idea what you're doing, except for that you know that you can do no wrong.

I had a DB manager decide to have a bright idea to upgrade our DB server the week before delivery to the customer. I thank God every day that he didn't have the key to the server room and the IT guys were obstinate enough to delay his upgrade until after the tested software was out the door along with a duplicate DB server.

He upgraded the server 1 week after we delivered the software and said everything looks good before he went on a month vacation. However, none of the software queries worked because they would work with the new system. It took the entire DB team a month to get everything squared away. When he came back from vacation, he wanted to do another upgrade. Fortunately management let him go at the request of everyone else on the team.

Everett:

God bless the PHB

I think the correct phrase is "God smite the PHB"

I would be curious as to know what kind of queries failed to function the same way under SQL Server 2005 opposed to SQL Server 2000.

I recently upgraded one of our products to use SQL Server 2005 from 2000. The upgrade was simply a matter of setting up rights on the new server, and then importing the old database onto the new server. That's it. I didn't have to change any queries or any code. Just had to point the app at the new server.

Granted, this app isn't doing anything too complicated but I'm still surprised to see stuff just out and out failing on 2005 vs 2000.

You're just trying to freak us out about Oracle and VARCHAR3, right? RIGHT?

and was the putz who did the upgrade fired?

why wasn't the upgrade rolled back rather than fire-fighting for that long?

The Real WTF here is that there was code that broke during an upgrade of SQL 2000 to SQL 2005! Seriously, that's not a major upgrade at all; I've upgraded a lot of servers like that and seen plenty more, and they all went smooth as hell. I agree this manager was an idiot to upgrade it out of schedule, but nothing should have even remotely broken due to it!

Captcha: cognac -- maybe the developers of this web app were drinking it?

ccanni1028:

And why would this manager even have the required access level?

<Lumbergh>Umm, yeahh, I'm gonna need the domain admin password this weekend. That'd be great.</Lumbergh>

I'd hate to work for a company where the managers had so little respect for process, production systems, or their own staff members who had specialized training. Cripes -- don't let him near the source code!

That manager should have been let fired immediately, or at least promoted to where he could do less damage.

Billy Bob Jamie Joe Hickboy:

He upgraded the server 1 week after we delivered the software and said everything looks good before he went on a month vacation. ... When he came back from vacation, he wanted to do another upgrade. Fortunately management let him go at the request of everyone else on the team.

That should (and usually will) happen to anyone in any enterprise who goes on vacation for a month at a time. If they can do without you for a month, they can do without you forever, even if you didn't bork anything up before you left.

database junkie:

I'd hate to work for a company where the managers had so little respect for process, production systems, or their own staff members who had specialized training. Cripes -- don't let him near the source code!

That manager should have been let fired immediately, or at least promoted to where he could do less damage.

I sympathize with your intent, but promoting this person would just create a plethora of wtf management (we don't need qa, it works as coded - just deploy it).

Sometimes you have to shoot the mad dog...

My guess is that there are several factors. The most probable being that the application was developed for an even earlier version of SQL Server. I am not intimately familiar with MS SQL Server (read: only test and student deployments) but it is easy to imagine an application developed for v6.0 which may have been supported by deprecated functions in SQL 2000, but those functions are gone in 2005.

Also, you may also be failing to consider the impact of moving from 32 to 64 bit. There are all sorts of data problems that can occur in any database undergoing such a change. Again an application coded for SQL 2000 32 bit shouldn't have many problems, but if the application is older... well.

Finally, the fact that it is MS SQL Server may itself be an obfuscation by this sites author to "protect the innocent." They could have been moving from MySQL to Oracle on Red Hat for all we know.

A Nonny Mouse:

a manager who had the foggiest clue on how to go about upgrading db servers? you must be kidding

How hard can it be? Insert CD, Upgrade? Yes, click, click, click and yer done...

Shoot, quarter, burn, hang ... not necessarily in this order though.

"That person should be sentenced to life in front of a firing squad" -Henry Blake

I make up my own captchas and they work!

captcha: sexytime!

...new language constructs, and, in Oracle's case, the introduction of VARCHAR3 and subsequent deprecation of VARCHAR2.

that's a joke right?

Oracle's case, the introduction of VARCHAR3 and subsequent deprecation of VARCHAR2

WTF?

Prefer the code WTFs myself; Too many process WTFs make reading seem like work.

The rogue upgrade should have been treated like any other system disaster. The systems should be have been restored to their backups.

Why would anyone go-live with beta quality code if they had the ability to restore to backup?

Makes no sense to me.

Yeah for managers who want to help!
Boo for managers who want to help.


My Captcha: PHB!

dbomp:

You're just trying to freak us out about Oracle and VARCHAR3, right? RIGHT?

Alex is only joking. That's because he doesn't know about that Unicode issue.

SomeCoder:

I would be curious as to know what kind of queries failed to function the same way under SQL Server 2005 opposed to SQL Server 2000.

I recently upgraded one of our products to use SQL Server 2005 from 2000. The upgrade was simply a matter of setting up rights on the new server, and then importing the old database onto the new server. That's it. I didn't have to change any queries or any code. Just had to point the app at the new server.

Granted, this app isn't doing anything too complicated but I'm still surprised to see stuff just out and out failing on 2005 vs 2000.

If it involves moving Analysis Services from 2000 to 2005, then G-d help them. Even without it, SQL 2005 is by default much more standards compliant than 2000 was, so you get errors where there were none before. Then there is compatibility with deprecated features that were in 2000 like *= and =* joins

Just testing this make-your-own captcha rumor.

Mine was supposed to be "gygax"

Derek Johnston:

A Nonny Mouse:

a manager who had the foggiest clue on how to go about upgrading db servers? you must be kidding

How hard can it be? Insert CD, Upgrade? Yes, click, click, click and yer done...

We had a Director of IT who was like this. His nickname became "Clickenstein". Favorite quote: "What's the big deal upgrading the domain controllers to 2003? Just put in the CD and click next...you're done"
Another favorite quote: "Server X is down...has Clickenstein been in today?"

Yeah, it worked.
I just typed "Sprite" instead of "gygax" and now "Marathon" instead of "doom".

Yeah, it worked.
I just typed "Sprite" instead of "gygax" and now "Marathon" instead of "doom"

A lot of managers get like that after reading "Upgrading SQL Server for Dummies"

Povins:

Just testing this make-your-own captcha rumor.

Mine was supposed to be "gygax"

Trying phony captcha - you should never see this

Actually, any query that previously assumed implicit conversion from one datatype to another (character conversions, specific case I've run into escapes me now) would fail, since Sql Server 2005 requires conversions to be explicit.

not a phb:

Povins:

Just testing this make-your-own captcha rumor.

Mine was supposed to be "gygax"

Trying phony captcha - you should never see this

Hmmm captcha was digdug, typed in gibberish and it took it.

Alex?

Just checkin'

I have some fairly large questions about this post.

I would be interested to see what kind of application would have so many queries that would break going from 2000 to 2005?

Seems like it would have to have a rather uncovential DAL to contain weeks worth of work to alter query logic between the platforms. Upgrading from 2k to 2005 is not like moving to another totally different federated base at all.

WTF is that i can't imagine a query that works in 2000 and will be broken in 2005, or this was really WTF query. Can anyone help with that? :) few our projects had 2000->2005 upgrade without any modification, only later some optimized code was added to work with new features.

I've worked for some small companies where you never who or when something was upgraded until things start going flaky and you finally figure out someone mucked with something when they say "oh, I just applied the latest upgrade to xyz software. I didn't think it would hurt."

Wow, don't do that, that hurt my heart. Ok, I guess it was funny. No, it wasn't.

I agree with what some other people are saying here... the 2nd WTF is that anything that worked in SQL2000 would stop working in SQL2005. Considering it's an upgrade, so it's the same server name/ip address, same accounts, same permissions, I don't even know how to write something that wouldn't work on purpose!

travisowens:

I agree with what some other people are saying here... the 2nd WTF is that anything that worked in SQL2000 would stop working in SQL2005. Considering it's an upgrade, so it's the same server name/ip address, same accounts, same permissions, I don't even know how to write something that wouldn't work on purpose!

Wanna bet? I don't know exactly about 2000->2005 issues, but when going from MSSQ7 to 2000, we had stored procedures that would flat out blow up on conversion. You see, the author of said procedures got the order wrong on certain arguments of the RAISEERROR() call. MSSQL7 would simply allow this, but 2000 would not, and the stored procedure would not be brought over.

So yeah, I can easily see issues with upgrading. The same goes true for anything: servers, MS Office, and especially OSes. You have to test, test, test. Of course, if you have a PHB around who just upgrades willy nilly like in today's article, then you're screwed. But at least they tried.

So I take it that this cowboy was subsequently publicly flogged before he was shot?

Alex Ibrahim:

My guess is that there are several factors. The most probable being that the application was developed for an even earlier version of SQL Server. I am not intimately familiar with MS SQL Server (read: only test and student deployments) but it is easy to imagine an application developed for v6.0 which may have been supported by deprecated functions in SQL 2000, but those functions are gone in 2005.

Also, you may also be failing to consider the impact of moving from 32 to 64 bit. There are all sorts of data problems that can occur in any database undergoing such a change. Again an application coded for SQL 2000 32 bit shouldn't have many problems, but if the application is older... well.

Finally, the fact that it is MS SQL Server may itself be an obfuscation by this sites author to "protect the innocent." They could have been moving from MySQL to Oracle on Red Hat for all we know.

Yeah, hadn't thought of that specifically. In general, a straight 2000 to 2005 port should be relatively painless (as long as you have a beefy enough machine to withstand the firepower of the bloated SQL Management Studio.. ugh).

I always thought of thedailywtf.com as an educational site. Not so much in it shows what to do, but what NOT to do and WHY not to do it. The queries would not have broken. Something else would have broken causing the queries to stop working. So if this article is to be of any value, can we at least be told WHAT broke after the upgrade?

If not, then where is the WTF? That the manager was stupid? Then I've already seen this article before. Like a million times already.

I like Tator Tots
Captcha: I do, really.

travisowens:

I agree with what some other people are saying here... the 2nd WTF is that anything that worked in SQL2000 would stop working in SQL2005. Considering it's an upgrade, so it's the same server name/ip address, same accounts, same permissions, I don't even know how to write something that wouldn't work on purpose!

DECLARE @ver nvarchar(128)
SET @ver = CAST(serverproperty('ProductVersion') AS nvarchar)
SET @ver = SUBSTRING(@ver, 1, CHARINDEX('.', @ver) - 1)
IF ( @ver = '8' )
--SQL Server 2000
--Do normal stuff here
ELSE IF ( @ver = '9' )
--SQL Server 2005
--Break stuff on purpose here

Edit:
I didn't test that code before I posted. I think maybe the SQL Server 2000 should be '7' and the SQL Server 2005 should be '8' instead of the '8' and '9'.

Hmm.... 25 paid vacation days per year is pretty standard in Sweden. So it's perfectly okay for an employee to disappear for five weeks. Four is more usual, though, the last week usually goes around Christmas.

Of course, it takes some careful planning to keep things running in July-August, but the good news is, most other people in other businesses are on vacation too.

Digitalbath:

travisowens:

I agree with what some other people are saying here... the 2nd WTF is that anything that worked in SQL2000 would stop working in SQL2005. Considering it's an upgrade, so it's the same server name/ip address, same accounts, same permissions, I don't even know how to write something that wouldn't work on purpose!

DECLARE @ver nvarchar(128)
SET @ver = CAST(serverproperty('ProductVersion') AS nvarchar)
SET @ver = SUBSTRING(@ver, 1, CHARINDEX('.', @ver) - 1)
IF ( @ver = '8' )
--SQL Server 2000
--Do normal stuff here
ELSE IF ( @ver = '9' )
--SQL Server 2005
--Break stuff on purpose here

Edit:
I didn't test that code before I posted. I think maybe the SQL Server 2000 should be '7' and the SQL Server 2005 should be '8' instead of the '8' and '9'.

i laughed pretty freaking hard after reading this. i had people coming over to my cube and ask me whats so funny