Don't read this if you don't like to read rambling griping...

-------------------------

For the longest time, Oracle was my least favorite database platform billed as "enterprise level". Now, I ceremoniously pass that gold belt to DB2. And here is why:

1. If you let connections pool, you get nasty "Cursor C1 already open" errors. Well, guess what the default behavior of their OleDb driver is? Yep, pooled connections. Of course,... pooled connections in an "enterprise" setting wouldnt be a very important feature to make work. Nah.
2. You want to only select rows from a table using OleDb where a certain field value is null? Tough luck, NULL support is unpredictable at best. Most times if you attempt to filter or join on a field that has null values, you wont get a resultset back. Period. No error, no warnings. Just no resultset (not even an empty one with field metadata but no rows).
3. Multiple statements in one batch? nope. Create a NEW connection every time and issue your query (no pooling, remember).
4. So you just want the database driver installed? Too bad, you must install the WHOLE ClientAccess/400 product to talk to an AS/400. (not small)
5. Oh yeah, this is talking about DB2/400, not the other flavors. I have no idea how bad they are, but I can imagine.
6. Speaking of DB2/400, if you want to pull data from a table (really maps down to os/400 "file members") then most likely you will need to specify system name and library in order for the object to resolve. If you haven't seen AS/400 system names, they are remarkably easy to remember and type. "S3059863" is an example. And of course AS/400's are still living in the 1980's and all objects are limited to 8 characters uppercase. This includes files and file members (a.k.a. tables and fields in SQL). Yeah. So to issue a SQL query it looks something like this "select GSDOCO, GSORG, GSCHGN1, GSHHYT from S3059863.SOMELIB.F59603 where GSJDMT > 105058". Why, of course that means "select the ID, sales rep, charge amount, and sales tax from the sales table that were updated after 2/27/2005". Or does it.
7. Oh, and half the time when you install a os/400 "service release" update, it breaks untold other things... with the DB2 interface being one of the common victims. Then, to fix your application you get a ClientAccess/400 service release. Which, invariably breaks yet something else. Fun stuff. This is why most as/400 systems operate a year or two (at least) behind current patching levels. It's just too scary to update your machine!

And whats the saddest thing about dealing with DB2 in this kind of environment? The cost of that hunk of iron is two orders of magnitude above even a significantly overarchitected system built using nearly any other architecture which would give comparable reliability and performance.

Sometimes, it feels like interoperability with an AS/400 via DB2 isn't worth the headaches.