Tuesday, August 7, 2007

Backwards compatibility

I've been a programmer for 20+ years. My current job is application maintenance, spanning at least three generations of web development philosophy and technology, for several divisions of a multinational corporation headquartered in Europe. I have users in the US, Canada, Sweden, France, Brazil, and Australia. And my co-workers in the cubicles right around me still ask me questions about mainframe development, which I haven't done at all in three or four years.

I know, both from all the third party software I've installed over the years and from applications I've written and/or maintained, that achieving backwards compatibility is a damned difficult proposition. After all, if programs were physical machines, we'd be talking about millions of moving parts in your PC. That said, it's a real pain in the butt when, say, an Oracle database gets upgraded, and you miss the memo informing you of the need to upgrade your Oracle client. I mean, okay, the production database is version 10, my client is version 9.2, and the test database is version 8; why can't I simply connect to test database to see if the Canadian test data loaded successfully?! After all, my tnsnames.ora file is correct, the DBA told me so. Or, at least it was before I tried to upgrade my Oracle client...

Let's compare it to the version on the test application server. Yep, they're the same. And my desktop tools still won't connect to the test database. Wait, there's another Oracle configuration file, sqlnet.ora; could that be the problem?

It is! Happy happy, joy joy!! Now, SQL*Plus can connect, so I have a command line tool; why won't PL/SQL Developer?