Thanks for this info. If possible it would still be useful I think to run the workflow. It should be simply a case of entering the full path for a test xlsx file (use a new name, as it will initially create it). And then run. Maybe it will throw errors somewhere, or turn up some info . If you are able to do so, posting back a screen shot of the output table might be useful.
It might even work, and if it does that will actually tell us something too.
One other thing though… looking at your workflow… if the new Excel Writer took just a little longer to write than the old deprecated version (to a network share perhaps!), this could throw up some issues in your workflow, because there isn’t anything stopping the Excel Reader from trying to read while (or before) the first writer is writing. Nor is there anything stopping the second writer trying to write before the first!
Could you try attaching output flow ports from your first Excel Writer to your second Table Creator, and then from your second Excel Writer to your Excel Reader (removing the direct flow to the Excel Reader) and see if that changes the result. At the moment you have no guarantee about the sequence of events in your flow and you might be at the mercy of network access, and sequencing the flow ports this way would resolve that problem if it exists.
I’m assuming that the deprecated Sheet Appenders aren’t trying to write to the same files within this flow.
Man, I don’t know with whom you are usually dealing with
Of course, I execute the Excel reader only after the writer is done. And I execute writers separately, for example: 1) remove the file 2) run the simple data writing 3) run reader to see the contents 4) run other simple data writing 5) run reader to see the contents. Basically, I use reader just for quicker checking what (and if) was written (much more convenient than opening the excel file each time). I am not running whole workflow, I am only running separate nodes - click on node, F8, F7.
I am not sequencing reader after writer [with variable connection] just because that would not allow me to freely run any writer I choose to test.
All four writers write to exactly the same path and file, except for “current” writers path is converted from string to a path variable.
BTW are you from KNIME team? We here are quite certain that we are dealing with a bug that arrived with new Excel writer and/or path data type. We can easily reproduce the problem with certain kind of file paths and the new Excel writer. Never had issues with same paths in same environment and old Excel writer.
You can try to map the path of your file folder as some letter like Z. So, the file will be referenced as Z:\File_name
I’m not making any assumptions about who I’m dealing with… … just trying to remove all possibilities… So thanks for the info though about how you are running that test flow. That’s another variable potentially ruled out which is good.
I’d still suggest running the workflow I uploaded even if you probably think it’s a waste of time. In my experience one of the best ways to find out why something isn’t working is to take something else that IS working and see what makes it break. So if you can see if that other workflow works, when I know for certain that it does work on my network share, then we can step towards maybe making it not work on yours and then find out why. That may then lead to helping establish if there is a bug. It may not. Anyway that’s your call.
And re your other question, no I’m not with the Knime team. I don’t think they’d want me…
Just a heads up. We think we solved this issue for the excel writer,however since we’re not able to reproduce it we’re currently forced to withhold a different functionality that we would like to add to another node.
Thx for all the great ideas and time you guys invest into helping us to reproduce the issue. Very much appreciated!
You can recognize the KNIME Team members right next to their names, as below @Mark_Ortmann and @Kathrin are colleagues of mine
@Mark_Ortmann Thanks! Let me know if we can help somehow with reproducing the issue.
@Iris Though so, thanks. Just the guy above seemed as interested as KNIME team in finding the issue Have you considered hiring him
@Mark_Ortmann Hey! Just checked if the issue still persists in KNIME v4.3.3. From initial simple tests - I can’t reproduce the issue anymore.
I wonder how it looks to others, like @rsemino.
Great to hear and sorry for causing you all the trouble in the first place. that nobody else is still experiencing this issue.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.