When loading a workflow built with knime 4.5.1 within the Knime 4.7.2, it seems the node doesn’t recognize the source and destination template file selection. It was set before as “relative to workflow data area” but then i found “Local File system”
Furthermore, even if i select the option to “override” the new file created, it is not stored in the component and the writing on the same file always fail.
I have found this behavior also creating a new workflow directly into knime 4.7.2.
Hi @albpesca_knime , what folder are those files in as those screenshots are only showing the file name without the full path.
If using the “local file system” option, I think I would expect to see the full path including the folders.
It’s difficult to tell though because maybe you have it set in a flow variable.
Could that be why it is not finding the files?
Or are you saying the files are still in the workflow data area, in which case what happens if you set the option back to “relative to workflow data area” ? Sorry if I’m misunderstanding.
Hi @takbb ! Thank you for your feedback! To explain better…i have migrated from 4.5.1 to 4.7.2 , also on the server side. When i download this workflow from the server, the node that was set to find the file “Relative to Workflow data area” , now try to find the file into “Local File System”.So, The configuration is missed.
Furthermore, the option to “overwrite” in the “Output File Selection” seems to not work. Even if i set it, i get an error as i had set to “fail”.
Do you know if the “write to excel component” is totally compliance with knime 4.7.2?
In terms of the file location, I don’t know why the setting would have changed, but are you not able to set it back to say “Relative to Workflow data area”? I would expect this to be working ok with the latest KNIME versions as I know it is widely used. I don’t have access to a KNIME server though, so maybe this is something I’m not aware of.
On the second point about the “write” failing even if you set it to “overwrite”, sorry I missed that bit in your original post. Yes this is a known issue, and the author is in the process of providing a fix.
