Instead of working, I blog.

We recently ran into a very interesting anomoly here upgrading to Yukon. We have the following query.


Select * from DWStsging.dbo.history

Of course, you all know the 3 part naming convention, so you know that DWStsging is the database name. However, what you may not know is that it's misspelled. The real name is DWStaging, and the one in the query is mistyped.

So what makes this interesting? SQL2K runs it just fine, and has for months, while Yukon spits it back at us. It's these little things that upgrading interesting.

These are the kinds of things I really don't mind though. Sure, it's nice that 2K does what you mean, and not necessarily exactly what you say, I'd rather my DB not make assumptions like that. So if anything, Yukon is forcing us to clean up our code where we didn't even know we had problems.

I just ran across this in an SP and I thought I'd share it with you guys...

Select RegionName from Regions
where RegionName IN ('SC', 'MW', 'NE', 'NC', 'NW')


For some reason, I just love the uselessness of this whole thing.

I’m sitting here playing with the new Word 2007 and you can set it up to post blogs directly. This is my first blog written and posted in Word 2007… now this is cool.

There's no such thing as varchar(1).

I just started a new project with a new group of devs. I feel like Jerry Springer because they're just spoiled children. They half-ass everything they do, and then run to the boss when things don't get sorted out right away.
It's amazing to me that these people can even function in society. I spend my time settling petty disputes, and fixing things that should have been thought through to begin with.

They constantly overwrite each other's code and blame it on someone else. They never backup tables before making major changes. They never verify SQL statements before asking me to run them. And most of it's just ridiculous crap.

You would think that since they have to work in their own dev environment, that they would manage it the way they need to, but instead they do the DB equivalent of sleeping with their cousins, and cheating on their sisters with their moms.

Let's grow up a little bit and start acting like we know what we're doing people. If you know the statement isn't correct then don't send it anyway. If you know there's a possibility you'll need to roll back a change, then backup the table first.

Here's the code for you:
Select * into NEWtable from ORIGtable

you can get fancier if you like, but that basic statement will get you by. Of course, if you wanna actually backup the DB first, that would be even better. LiteSpeed has object-level recovery so you should be able to pull back individual tables and schema code.

Stop running around like children making half-ass changes. Learn from your mistakes. If it keeps coming back to bite you (and it does), then stop doing it. You'll find you'll start making your deadlines and even getting to bed on time.