DB Connector locking my database user

Hello all,

We have recurring problems with our users in a Oracle database, which are being locked periodically and we dont know the reason. Could be posible that DB connector nodes (successfully executed previously) in an old executed workflow are causing this by triying to connect again to database or whatever when open again those workflows or jobs?

Example: This is the error we get of a metanode when we open a previous job in our server, which incudes a DB connector node previously executed without any problem. Aditional info: we use a credential flowvariable to configure these connections.

Our DB mates cannot give us any additional info about the faulty connections which block the accounts. Any suggestion?

Thanks in advance.

Hello jricgar,
if the Credential node and the Oracle Connector node or any other DB Connector node are saved in executed state the DB Connector node will try to recreate the connection to the database upon workflow loading. If the “Save password in configuration” option in the Credential node isn’t enabled the DB Connector node will try to login to the database with the given user namen but no password since it is not available. If you have several connector nodes in a single workflow all of them will try to connect to the db without a password which will fail and might cause the user blocking. The only workaround I see is to reset the DB Connector node before saving.
We are thinking about adding an option to the Advanced tab of the DB Connector nodes which will allow the user to disable the connection recreation when the workflow is loaded. Would this be a viable option for you to explicitly disable the connection recreation?

1 Like

Hi Tobias,

It will be great to have that option. In the meanwhile, I suppose we will have to enable the “Save password in configuration” option in order to avoid these problems and also to keep the workflow as executed and with the results available.


1 Like

Oh wait, we already enabled the “Save password in configuration” option in the Credentials Input node some time ago… :thinking:

We always use a configuration metanode template which creates the db credential flowvariable depending on the execution enviroment. Then we use this credential flowvariable several times around the workflow, in several DB Connector nodes. But the Credential Input nodes we put inside that template are always configured with “Save password in configuration” option enabled.

What are we missing?

No one?

Still having problem with this issue. We have to ask periodically our DB colleagues to restore our blocked database credentials due to this behaviour.

We have been using Credentials Input nodes (Quickforms, now legacy) in KAP 3.7.2. After updating KNIME to 4.0.2 last week, our credentials were blocked again last weekend. So today we have just substituted these nodes with Credentials Configuration nodes, which we assume are identical, aren’t they?


Hello jricgar,
sorry for the late reply. Somehow your response slipped my attention. Unfortunately I don’t think that the issue will go away by replacing the Credential Input node with a Credentials Configuration node.
All these nodes will provide the stored user name and password to the DB Connector node which will use it to recreate the connection to the database. Do you need to frequently change the password of your oracle login. In this case the DB Connector node will use an out-dated password and thus might log you out if to many connector nodes try to reestablish the connection.
Can you send me a workflow with the metanode template that creates the db credential flow variable via pm or the KNIME support. Maybe this causes some unwanted side effects.

We have just check that new credentials configuration nodes are even more complex because they cannot be disabled. I mean, when using credential input nodes you can use the “Change” check to overwrite the node configuration, which by default we control with flow-variables (for example we get user from knime context, put it inside a flow-variable and then use this value for the default user value in credential input node). In that way users can choose to maintain default credential values or change them. Now this is not possible.

Furthermore, with credential inputs you can choose to hide user in order to maintain default value (context user) and only show password field to be filled. Now with credential configuration, you can hide user field but then IT IS ALWAYS overwritted by dialog with “” value, so you loose the flow-variable default value.

I will send you our credential component (using new credential configuration nodes).


Hey jricgar,

the credentials configuration node keeps the default value until it has been changed in the component view for the first time. From that time on it will always overwrite the dialog value. I agree, that this behavior might be unwanted and that there should be an easy method to switch back to the default value. I will open a ticket in our system for that issue.

Your second issue probably results from the same cause. If you have changed the username field in the component view to an empty field before you disable the user input, this will still overwrite the value. If you leave the field unchanged and then disable the username input it should work as expected?

I hope I could help you and feel free to ask any question.


Hello jricgar,
we have just implemented the option for the Advanced tab to disable the connection recreation when a workflow is loaded

For all newly created Connector nodes this option will be disabled. For all existing workflows we will enable it to be backward compatible.
The option will be available with the December release.


Hello Daniel,

If you leave the field unchanged and then disable the username input it should work as expected?

We have returned to input nodes, avoiding to use the new ones (configuration nodes), because inputs have disabling checkboxes. So we haven’t tested what you suggested lately. But anyway I quite sure this is what we did initially.


Hello Tobias,

We are back with these account blocked problems. But in this case, it is even more complex, because our data process includes a job on server and its interaction with KNIME Analitycs Platform locally. Could be possible that a job previously executed on Server, when opened locally on KAP, was also trying to check or restore an existing and expired database session? I suppose yes, but furthermore, would be possible that this happens every time that KAP tries to sync that job with the server (which happens continuously when the job remains open in KAP, every X seconds)?? Our DB Connetor node it’s included inside a shared component, maybe this is also something to be taked into account…

Today our database’s user account was blocked two times, and the only one reason we can imagine is that an executed job was opened in my local machine on KAP.


This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.