Bug 105684

This is related to issue 84654, that a lot of people are hitting.

From the Wiki, Lance says:
am not sure what you mean by out of date. Are you suggesting that a JDBC driver is not at a minimum JDBC version? What
should happen is NB should check the JDBC major version via DatabaseMetaData.getJDBCMajorVersion() and then call the
method that should be available. Trying to track driver specific versions is a no win scenario - Lance

I say:
I don't know what the errors are that cause older drivers to fail. If it's because we're calling the wrong method, we
could try and call the right method, but I think it's bugs in the drivers that got fixed in later versions. I also don't
want to spend time trying to support older drivers. why is tracking driver versions a no-win situation? P.S. I'm moving
these comments to the issue, and we can continue our conversation there...

I just remembered there are two places where metadata can be a problem, and where people get confused: in DB Explorer,
and at design time in the visualweb module.  

These two places use two different mechanisms to obtain metadata.  DB Explorer uses DatabaseMetaData.  In visualweb, the
metadata is for a particular command (e.g. "SELECT foo, bar FROM baz") and thus can't be obtained through
DatabaseMetaData.  Metadata is obtained instead from the RowSetMetaData from the rowset underlying the query.

Also, visualweb right now may have a different list of drivers that it supports versus Database Explorer.

We should probably create a separate issue for visualweb, and leave this one focused on the DB Explorer...

Unfortunately, things aren't simple here.

As Lance says, I don't think we should get into the business of tracking specific driver versions.  

We can check the JDBC major versions, and report a mismatch there.  That would catch the case where the have a really
old version, but otherwise that's rarely good enough.  Drivers will claim compliance with a particular version, but fail
on specific calls.  They may even return a result which is incorrect, which is a Bad Thing.  Even drivers that we
support may be missing functionality.

What we should do, IMO, is to respond appropriately when we hit a missing or incorrect method.  We typically discover
those empirically, as users report problems and we put checks into the code.  I think this is more effective that
checking driver versions, because we need to do it anyway.

We should also make sure that we have an up-to-date list of supported drivers in our release notes, but that goes
without saying.

Other than the check for the right JDBCMajorVersion (which can probably be done when the connection is created), I don't
think there's much to do here, except to ensure that we catch and respond appropriately to driver failures.

I'm no longer working on this right now, so I'm trying to move it from the STARTED state.  We'll see if reassigning to
me does the trick.

Reassigned to new owner.

I would close this bug as wontfix - I doubt there will be enough manpower to maintain a white list and a blacklist won't do much good.

One idea: To leverage the differences in the DBMS not caught on the JDBC level one could use the hibernate dialect approach or the eclipselink counterpart. By doing this the big communities and joint resources of both projects could be used. Problem: Both projects consider their dialects internal ...

No further comment after 2 years and no work done also. The mainstream jdbc drivers work as expected - I saw:

- mysql
- javadb/derby
- mssql/sqlserver
- informix
- postgresql
- sqlite
- db2

working. So closing this as announced.