SQL Server JDBC 2.0 Driver

25 views
Skip to first unread message

Jeffrey Mo

unread,
Mar 2, 2010, 11:36:38 AM3/2/10
to architect-...@googlegroups.com
Hey everyone,

I came across this issue working on the SQL Power DQguru project, but since I think this will affect any project dependent on the SQL Power Library, including the SQL Power Architect, I decided to bring up the issue here as well.

I was looking to replace our current bundled SQL Server driver with the latest one from Microsoft because the one we bundle now does not support SQL Server 2008. It gives you a SQLServerException stating "The server version is not supported. The target server must be SQL Server 2000 or later".

So as I discovered to my annoyance last night, Microsoft decided to make their latest JDBC3 driver not work when running in a Java 6 VM. Yup, it throws an exception saying that it doesn't work.

More specifically:
java.lang.UnsupportedOperationException: Java Runtime Environment (JRE) version 1.6 is not supported by this driver. Use the sqljdbc4.jar class library, which provides support for JDBC 4.0.

I don't of any other vendor who does this. Anyway, the point is, assuming we're sticking with Java 5 support for now, we would have to ship both the JDBC3 and JDBC4 driver for SQL Server, as well as provide two pre-set database type configurations for both.

I was considering replacing that whole mess with the open-source (LGPL) jTDS driver (http://jtds.sourceforge.net/), but there are some other considerations:

1) Projects other than the Architect share the default_database_types.ini in sqlpower-library, if I change it for one project, it will impact all the other projects as well. Even if I decided to make a custom branch of sqlpower-library just for this change, it could conflict if someone decided to install, for example, DQguru along side Architect. So if I change the driver for one project, it would be best to change it for all.

2) Perhaps there could be issues with the sqlpower-library JDBC wrapper for SQL Server with the jTDS driver since it would've been written specifically for the Microsoft driver? Although I suppose we could just configure it to not use a wrapper.

3) jTDS is a JDBC3 driver (it makes that pretty clear on their website), so if we decide to move onto using the JDBC4 API in our library code, perhaps this may become an issue in the future?

I suppose one other option would be to say 'forget Java 5 support', and only include the JDBC4 driver.

Since this decision would impact multiple projects, I wanted to get feedback from other developers before going forward.

-Jeff




Reply all
Reply to author
Forward
0 new messages