Danger, Will Robinson!

I think the danger in being a computer geek is that you know how things ‘ought’ to work. You plan all your dangerous maneuvers based on how you know, from all the times you’ve done it in the past, how it will work.

And of course, it promptly doesn’t work properly.

It’s a simple thing I wanted to do. I wanted to update some rows of data where certain conditions exist, to correct for a problem that happened back in pre-history. Simple. Basic database manipulation. OK, granted, the ‘where’ statement was a little on the twisty side; if this then do that other thing to see if it is slot A or slot B, return C if neither kind of stuff. But still, not all that difficult. Basic stuff. Advanced beginner SQL coding.

Or would have been, if I weren’t having a day where I want to sell everything I own, eschew computers entirely and move to a llama farm. Because what ‘ought’ to work ain’t workin’ and what I shouldn’t have had to do I had to do and what I expected to take about two hours tops instead took six.

The worst part, of course, is that what I was trying to do was back out a, um, well. “Mistake” is such an ugly term. I prefer to call it an “unanticipated output”.

Thankfully, only a handful of people are actually working today so I think I managed to get the restore to @*^&ing restore before anybody had a chance to go, “Heeeeey…what happened, how come all the fields are purple? Where did the names go? What’s…what’s going on?! OH MY GOD! It’s the END! END, PEOPLE!!!!”

It is never fun to explain to your users that you had an update statement mishap and that you’re working on a timely solution. You can’t explain what you’re actually doing to the non-geek because the terms may cause them to fall over stone dead either from shock or in an attempt to make you stop saying words like “WHERE FROM HAVING INTO JOIN BY” all in a blather.

Yet when you try to just say, “Technical difficulty, please stand by”, what do they do?

“What kind of difficulty? Well, what are you doing about it?!”

Before you know it… “Well, the WHERE didn’t mesh with the HAVING and the JOIN ON was missing a clause which caused the SUBQUERY to return…” {{THUMP!!}}

Drat. Killed another end user.

What’s pissing me off is that I very carefully backed up my data into a mirror table. I should have been able to simply say, “Whoops, hang on, that didn’t actually work the way my tests indicated it would…I’ll just go ahead and rename this table to X_DEL, rename the backup table from X_BU to X and start over.”

But ooooooooh no. “General system error: Action not permitted.”

Whaaaaat?

It only got better. I got ‘you must be logged in as a sysadmin to perform this function’ (um…I am the sysadmin…ALL BOW BEFORE ME!!!). I got ‘Truncation not permitted – contact sysadmin for more information’. I got ‘General network error 18672986712: System not found.’

WHAAAAAAAAAAAAAAAAT!?

Of course, the whole time, I could do other data manipulation just fine. I just…wasn’t allowed…to rename tables.

What.
The.
Heck, people?!

So naturally, instead of just working around it and getting ‘er done, I puttered around trying to figure out what was really wrong, here. Because I knew how it ought to work. I’ve done it that way a zillion and a half times over the last fifteen years. It works, every time. Except this one. So let’s go ahead and worry about why it isn’t working, rather than figuring out what would work and moving on with our lives.

This, friends, is why I say computer geeks are a race apart. We are genetically incapable of just letting it go. No no. It ought to work and dammit, I’m going to spend the next five years of my life, if need be, to figure out why it isn’t working per my plan.

And the more experienced we are, the more we do it. See, if it were…ten years ago? Five years ago, even! I’d’ve gone, “Wow, hey, that isn’t working, I must be doing it wrong, I’ll just {insert one of five other ways to do the same thing here}!”

But no. I know too much! I know it ought to work! {Grows old trying to force something that ain’t working to work, damn you! woooooorrrrrrrk!!!!!}

And then, oh oh oh, get this: the backup table I had made decided that I didn’t know what I meant by varchar and obviously I had meant float.

So when I did realize I was redefining insanity (insanity: doing the same exact thing over and over again, expecting different results) and turned to Plan B, all my product numbers turned into these weird things with decimals so I couldn’t even delete all the data from Table 1 and replace it with the backup data from Table 2 and honestly by that point I was about ready to give it all up for a nice safe career as a Sherpa. Ah yes, carrying tourist luggage up Everest, that’s the life for me! (Said the woman who can barely walk up her stairs some nights…)

Much cussing and kicking and shouting obscene words at the screen later, finally, I got everything back the way it was before I messed with it.

And then I made coffee.

And then, to add insult to injury, as I was standing there at the machine waiting for the pressure to come up enough to steam my milk, I realized that there was a far easier and safer way to do my manipulation: Port the data into Excel, do my nested ‘IF’ thing in Excel, export the results back to an update table, join the two together and run the update off the proven-with-my-eyeballs results from Excel.

(Did I just hear a series of {{THUMPS!!!}} out there?!)

So I did, and the !WHOLE THING! took, like, half an hour. All tests indicate that in this case, Excel rocked the free world. From a solid paragraph of CASE statements to a single cell’s worth of nested IF, with conditional formatting to highlight…

{{THUMP!!}}

Oops. Better stop with the geek-speak before the police arrive and haul me away for wholesale murder of innocent blog readers.

Anyway – this is what y’all are missing, who have successfully avoided the geeky world of databases. Tune in tomorrow, when I find out that what I did wasn’t at all what the user wanted…