string manipulation multi column resets configuration every time I open my workflow

In my workflow, I use String Manipulation (Multi Column) to change two fields to upper case. I am using Knime 5.2.3. Before I upgraded from 4.x, this node worked normally.
I set it up with two fields ([first name] and [last name]) in the “Include” area and saved the workflow.
When I open the workflow, I have to reset the initial node that reads in data from my data source. This triggers a reset of all downstream nodes. Then, when I check the config of the String Manipulation, it has every field in the flow selected in the “Include” area. I fix it, save it, and again, when I reopen, I have to edit the node.

Again, this did not happen with the same workflow using Knime 4.x.
It doesn’t seem like correct behavior for a node config to reset like this.

Is this a bug in the node? In version 5.2? Something I’m doing/not doing?


Hi @LB_Knime , can you share screenshots of your String Manipulation (Multi Column) config, for both 4.x and 5.2.3, or better still do you have a minimal worflow example you can share, which exhibits the issue.

I tried what you describe as best I can from what you describe (albeit in 5.2.2) and it works ok.

Have you got “force inclusion” or “force exclusion” set?

Do the column names (or the number of columns) change when you refresh the datasource?

Thanks for the reply.
Attaching screenshots.
Knime node reset issue
Column Renamer sample

I thought it might caused by the preceding node which was the deprecated Column Rename. But I replaced it with the new Column Renamer and now the issue is moving upstream.
I am using a DB Reader and have to reenter my credentials each time I open the workflow. When this happens, the Column Renamer node loses all it’s existing column names.
Maybe I should move the renamer further downstream?

Hi @LB_Knime , when the preceding nodes are in the “red” state as in your screenshots above, I would expect to see the Column Renamer and the String Manipulation (Multi) configs looking the way they do, but when the you re-execute the workflow, you’re saying it doesn’t automatically put the column names back?

I’ve added a Column Renamer node into my own dummy workflow,


and reset the nodes, so Column Renamer shows this:

an String Man (multi) shows this:

but when I simply execute them (leaving the config unchanged), the config gets remembered, and returns:

That doesn’t happen in your case? Then what does your Column Renamer and String Manipulation (multi) config show when you execute the nodes?


Ah ok… I can see that this is actually a behavioural difference between 4.x and 5.x

4.x (after reset of Table Creator)

and String Manipulation multi shows the columns from previous execution

5.x (after reset of Table Creator)

and String Manipulation multi appears to “forget” the columns from previous execution

which does feel confusing, and a retrograde step in 5.x, which I hadn’t noticed before.

You shouldn’t need to edit the config though. 5.x should re-remember it when the previous node is executed. Then it will go yellow, and “remember” the config

My summary here would be it isn’t to do with the presence of the Column Rename(r), as you can see it in action above even without renaming columns. It does feel that something has changed “under the hood” with the way 5.x resets the flow.

1 Like

I reran my workflow - executing from the node just after the String Manipulation.
It failed at the String Man. node again.
Pasting a shot of the error message.

Node error msg

And the configuration view - you can see how the node now wants to process every field available. (I can scroll down in the Exclude pane to see the currently available fields - they are all there.)

I relocated the Column Renamer further downstream and reset the workflow. It appears to be behaving according to the expected behavior you outlined above, @takbb .
The whole thing takes over two hours to run, so I’ll get a true test tomorrow morning.

Hi @LB_Knime , manually set the String Manipulation (multi ) to just include the 2 columns firstname and lastname, again, and then make sure you have “Enforce inclusion” selected.

Currently, because “Enforce exclusion” is selected, if the node is passed columns that weren’t there at configuration time, it will try to include those too, which I think is what you are seeing.

Thanks. That makes sense. I’ll try that and report back.

Thank you very much, @takbb - that solved it!
I appreciate your time.

1 Like

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