Instead of working, I blog.

We're currently setting up Informatica and we got some scripts from them to create the DB. There were 3 scripts in all. The first script went ok. The 2nd had some problems, but it was small enough that I was able to just fix them and get past it in fairly short order.

The 3rd however was just pathetic. Not only was it huge, but it was plagued with dozens upon dozens of errors. The header of the scripts says that they were written and tested in SQL Server 7.0. WHAT? You haven't updated your scripts in 10yrs? Not only that, but with the errors I was getting, there's just NO WAY they ever even ran on SQL 7. It's mathematically impossible. Here are the problems I remember... there may have been more.

1. Deleting tables before they're even created. They should have put an IF clause in there.
2. They were deleting PK tables before their FK tables were deleted. Excuse me guys... have you ever heard of referential integrity?
3. They were creating relationships with data types that didn't match, so I got TONS of errors that the 2 column in the relationship had different data types. I don't even see how this is possible.

Frankly, I'm not only disappointed, but somewhat shocked at the lack of skill a company like Informatica displays here. My mother could write better SQL than this. There's no way this code ever ran. I've even got a VMWare image with SQL 7 on it, and I ran it in there, and it bombed too, so don't give me any of that wrong version of SQL crap.

It really does make you wonder though. How many people are actually using Informatica? Because for them to send a customer such pathetic code, it clearly hasn't been tested... EVER.

And this isn't the only bad code I've ever received from a vendor. It seems like somehow none of them can write SQL that runs worth a damn. It really doesn't seem that hard does it? Because I've written hundreds of scripts, and when I'm done, I run it. It either runs well or it doesn't. If it doesn't run without errors, I fix it. Go figure! And some mistakes are understandable, but like I said, there's no way that dropping a table before it's created has ever run without an error. The code was simply never run against a DB.

I can probably tell you what happened though. The developer already had the schema in his DB and he was getting errors when he needed to create the tables so he added drop statements. I guess it never crossed his mind that someone might be installing for the first time. The other errors however... there's just no way he ever got the rest of that script to run.