Well, the story goes like this.
Once you have a closed source application to extend (well, you decomiple it of course, but it doesn’t make it open source, do it?). And it is damn old (like 2001 or something, did people actually code then?). And it uses some weird database like MS SQL Server, and, of course a JDBC driver for it, jTDS. Back then, in 2001 version 1.0 of the jTDS was available. It was a little very buggy, for example, putting the driver’s jar in WEB-INF/libs generates NPE, so it have to live in Tomcat’s share lib.
And of course, as any respectable company the vendor of the application developed it’s own wrapper arround JDBC with DatabaseUtilities.getConnection, releaseConnection, and so on.
Now, to the story.
On the surface it looked easy. We obtain connection, bla-bla, executeQuery, ResultSet.hasNext, etc. Works like a charm on clearly installed application. Once they populate the database with their home-made utility for migration from excel… boom. Thier code works, our throws IOEXception – “system cannot find the path specified”. The root of the exception somewhere inside the driver. Google suggests to update the driver to the last version. No prob! Done. Of course I move it from Tomcat’s share to the application lib on that occasion.
Guess what? Our code works like charm, but all other updates in application start failing on it can’t manually commit when auto-commit is on! As I understood it, they just didn’t turn auto-commit off, and the old buggy driver forgave them!
What can you do? The old driver stops working on durty database, the new driver won’t work with their application code. You can’t change the source of their driver wrapper to turn the auto-commit off, because it is closed-source, and you can’t be sure decompiler did a perfect work (and usually it don’t).
Anyway, we rolled-back the driver version, returned it to Tomcat’s shared lib, and went to their JDBC wrapper to look which shaman ceremonies they perform to make it work. We’d better not. They cast the driver to the actual jTDS class and call all kind of implementation methods. I am thankful to them they wrapped all those inside their JDBC wrapper, so all we needed to do is to replace JDBC code with some really strange calls like getQueryResults, which gets the SQL string (not parametrized, of course), and returns array of strings (contatining all the data, including dates and numbers).
So, what do you say? Any better way to do it except coding to the bug?
