I've encountered an issue with the (otherwise much appreciated) SQL Server connector in KNIME 3.3.0; see below for the error message thrown:
ERROR SQL Server Connector 2:2292 Execute failed: Could not create connection to database: Java Runtime Environment (JRE) version 1.8 is not supported by this driver. Use the sqljdbc4.jar class library, which provides support for JDBC 4.0.
By now I'll go back to generic JDBC connectors, though I'll have to restart KNIME 3.3 for this to have SSO work... :-)
Just configuring a database connection node - maybe it's my "Parameter" setting? I need to set "instance=INSTANCENAME;integratedSecurity=true" as per the raw JDBC conn string.
it seems that you registered a MS SQL Server driver via the KNIME->Database preferences page which isn't compatible to Java8. The new SQL Server Connector node by default uses the free jTDS driver but uses a user registered driver if it exists. I wonder why it is working with the generic Database Connector node which uses the same driver. Can you send me some more information about the driver you have registered e.g. vendor and version and the driver class that you select in the Database Connector node?
We've registered both jTDS and the official MSSQL JDBC drivers - jTDS in fact has a bug with tinyint types, so "going official" was better for us, and it might be for you guys as well. :) Then again your native connector nodes ensure that types are handled nicely, don't they? That's really my main interest with the connectors...
Anyway, so deregistering conflicting JDBCs might help me, but it's very inconvenient since there are tonnes of legacy flows depending on the manually installed JDBCs... :-/ Any chance of you being able to de-conflict on the basis of internally renaming the driver(s) you integrate?
Thanks,
E
P.S.: I'll check for driver compatibility with Java 1.8 on my end and report back about that, too.
I have ruled out the major release version of Java 1.8, since that was already the Java version in KNIME 3.2.1, in which everything runs fine with custom JDBC drivers (didn't try the packaged one back then -- if it was around already to begin with).
I do, however, not only encounter fundamental connection problems with the packaged SQL Server connector, but also with SSO support in my trusty custom jTDS 1.3 (with the SSO DLL being in the right place) and with the official MS-JDBC. Both were working fine for me on 3.2.1.
So in essence: no coonection at all with packaged and MS-official user drivers, and no SSO with the jTDS user driver. In 3.2.1 both MS and jTDS user drivers fully worked, SSO included.
On the basis of that status, are there any further routes of investigation you can propose?
Any chance of you being able to de-conflict on the basis of internally renaming the driver(s) you integrate?
we plan to allow for multiple installations of the same driver e.g. with different versions. The user can then assign each driver a unique name which can then be selected in the cooresponding connector node. Right now this is all based on the class name of the driver which is why we can not change it right away.
yes we change to Java 8 with KNIME 3.0. Do you have the problems with the generic Database Connector and the new SQL Server connector node? The major thing we changed was adding the new connector node which as of today does not support SSO since we do not register the required ddl. Adding SSO support with the SQL Server Connector node is on the list of enhancements.
In general KNIME always preferes any user registered drivers over the build in drivers. So if you have registered your own version of the jDTS driver KNIME is using this one in the database connector nodes. You can check this in the KNIME log where we log which driver with thich versions is used. Could you please have a look at it to see which drivers are used in your case.
The line looks like the following if an internal driver is used:
DEBUG Database Connector 0:161 DB driver: org.h2.Driver found in driver factory: org.knime.database.connectors.h2.utility.H2DriverFactory. Driver info: Driver class name: org.h2.Driver major version: 1 minor version: 4 jdbc compliant: true
and for user defined drivers which it should be in your case it looks like this:
DEBUG Database Connector 0:161 Database driver retrieved from user defined drivers: oracle.jdbc.OracleDriverDriver info: Driver class name: oracle.jdbc.OracleDriver major version: 12 minor version: 1 jdbc compliant: true
Many thanks, I'll dig further into this next week. By now I've returned to KNIME 3.2, which does solve the problem I reported for the regular custom-driver connectors we used before.
I also have a lingering suspicion that our virus scanners do not like the latest JRE (or Eclipse) bundled with KNIME 3.3 and somehow block it from accessing the network, since my proxy settings show the same misbehaviour between 3.2 and 3.3. KNIME's start-up and the loading of workflows also take substantially longer with 3.3, so something isn't quite right overall -- maybe it does explain it in the end, maybe it doesn't.
I'll report back once I could firm up some things.