we have an old workflow from 3.7.2 and wanted to update the database nodes to our current version 4.1.3. We tried the normal database connector and the oracle db connector and found a strange behavior. If we enter a username and password in these nodes and execute that node under Windows it works fine. If we transfer the workflow via KNIME Server to a Linux based KNIME Desktop the same node fails, because it complains the password is wrong. Entering the password again lets the nodes work again. I also tried to use the credentials functionality and had the same strange behavior. Does anyone know whats going on here?
Many thanks in advance!
Hi @laval -
Interesting… what specific error message are you seeing as a result of this?
I attached a screenshot of the error message.
Furthermore, I think I found the reason for the issue. Under Windows an Oracle driver in version 11 and under Linux in version 12 was used. This seems to confuse KNIME. For testing I used version 12 in both systems now and the error disappeared. I have no experiences with db-nodes and don’t know if this is still unexpected behavior.
We really like the legacy nodes - how long can we make use of them until we run into issues? One nice feature I see in our old workflow is the optional input for the DB connector, which allows to use the legacy db node without a connector for many times in a huge WF.
I tried to reproduce the problem but failed to do so. What I did was create a workflow with Windows10 that contains the new Oracle Connector node using version 12.2 of the Oracle driver. I then transferred the workflow via a KNIME Server to a KNIME running on Ubuntu and registered version 19.6. of the Oracle driver and I could connect to the database. The password contained letters and numbers.
We recommend to use the new DB nodes wherever possible since it is only a matter of time when the legacy node become deprecated. We will communicate the end of the legacy nodes in advance to give you enough time for the migration.
Regarding the mandatory connector node in the new framework, it was necessary since the connector now controls the db session live time whereas in the old framework only a single connection existed per user and database. If you encounter any other problems with the new nodes let us know.
thanks a lot for looking into this. I would like to give a little more information. The OracleDB was used via Windows10 and the old DB-nodes using a driver named obcd6.jar Inside of KNIME. After changing to the new DB-nodes and loading this driver the KNIME preferences it tells driver class:11.2.0. Now we wanted to use the same Workflow also under Linux (Debian9) and there we use the file obcd8.jar which is mentioned in KNIME preferences as driver class: 12.2.0
And here we had the issue under Linux then. But after openening the configuration of the node and saving that with ok it worked fine. So in my understanding it is either an issue between the drivers itself or a change in the configuration of the background of the DB-node which needs to be automatically overwritten after opening. Unfortunately, I can just share the jar-files, but noch the DB itself.
By the way, the effect was the same for using the Oracle-DB-Connector or the main DB-Connector.
But for us was the solution already, to use the same obcd.jar-file. I was not aware, that the Windows user used another obcd.jar-file.
All the best,
we are now starting to change our workflows towards the new DB nodes and we had a similar issue again.
Under Linux new nodes work and if we switch to Windows they ask “Please select a database type”. If I open the configuration of the node everything looks fine. If I say OK then it runs and if I cancel it does not run.
If I use the now under Windows running workflow under Linux again I am having the same issue there.
After investigating what the differences are, the only thing I found was that the ID was shown under Linux as “Oracle” and under Windows as “oracle”. After reinstalling the driver with the ID “Oracle” under Windows the exchange over the OS worked fine again. Is there a way to prevent such issues in the future? The old db nodes never caused such problems. Unfortunately, I did not find a way to hardcode the ID in the setting files.
As you described, the order of operations was like:
Windows/Driver A (odjb6)/runs
upload wf to KS
download wf from KS to linux desktop (or open from RWE)
run wf on linux desktop
observe issues with db connector
This may be an issue with the driver behind the db connector having different versions in the different environments; the recommendation is to ensure that you are using the same driver in all environments as you have noted.
but this time we did learn from the old driver incompatibility issue and use the same driver odjb8. This time we had a new unexpected issue which I described in my latest post, which was only related to the ID inside of the driver settings in the preferences of KNIME - capital letter versus lower letter in the word Oracle.
Thanks for the clarification. I’m glad that you were able to get that worked out, and I’m sorry that you had some issues with it at first.
Please let us know if you have any additional questions or concerns.
first of all I wanted to make aware of these issues, since nobody else seem to have them too. Furthermore, I am looking for a guide on how to setup and use these db nodes in the best possible way and to avoid further issues. The old database nodes just worked and I assume we need a learning curve to handle the new nodes. After a long journey of unexpected behaviour they work now for us.
Apart from the question if I can preset the ID in the usersettings somehow when sending the epf file via the KNIME server, I am wondering why there is the general db connection node and the oracle db connection node. I got the impression the full Oracle functionality is already included in the general node. So why is there an extra node for Oracle, which does not seem to have any other features? Am I missing something? When should I use which node?
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.