Hello @ all,

there is a weird behaviour in a job which I can't explain.

A couple of *.txt files is downloaded. Then renamed to *.csv and uploaded by sftp. Sometimes the upload responds "no files found" even if a previous task is showing a rename from txt to csv. If checked on the server there is really no file.
Where does the output message from the previous task come from - is there a file renamed or not?
The path where the files are stored contain the german umlaut "ä" - is this a possible reason?

@ development: An separate logfile with full output for a single job would be helpful.

Kind regards, Martin

Hello @ all,

there is a weird behaviour in a job which I can't explain.

A couple of *.txt files is downloaded. Then renamed to *.csv and uploaded by sftp. Sometimes the upload responds "no files found" even if a previous task is showing a rename from txt to csv. If checked on the server there is really no file.
Where does the output message from the previous task come from - is there a file renamed or not?
The path where the files are stored contain the german umlaut "ä" - is this a possible reason?

@ development: An separate logfile with full output for a single job would be helpful.

Kind regards, Martin

You should be able to see where it goes wrong in the output. It's either that no files were renamed, no files uploaded or no files downloaded. Is it possible for you to export the job (without the ftp credentials, we can try it on our own) and send it to support@visualcron.com ?

If not, then take screenshots of all settings to the relevant/problematic tasks and upload here or send to our supportmail.

---

Task 4 is a simple SMB copy statement, which copies up to seven different files.
After this a rename of this files to *.csv is done in seven tasks - where "no file(s) found" is not set, because not all files are there every time.
Then a sftp upload with mask *.csv is done - which fails sometimes.

Yesterday the output of the last rename was:
D:\[...]\Import\Filialen.txt > D:\[...]\Import\Filialen.csv
And the following sftp task with mask *.csv hat the output (error):
Exception in Task: No file(s) uploaded

I triggered all tasks manually one-by-one this morning, everything went fine. I activated "Extended Task debug logging", hopefully I see more details in the logfile, but all jobs are writing in the same file and dont have any job-id in the lines. Is there any further logging possibility?

Regards,
Martin

Task 4 is a simple SMB copy statement, which copies up to seven different files.
After this a rename of this files to *.csv is done in seven tasks - where "no file(s) found" is not set, because not all files are there every time.
Then a sftp upload with mask *.csv is done - which fails sometimes.

Yesterday the output of the last rename was:
D:\[...]\Import\Filialen.txt > D:\[...]\Import\Filialen.csv
And the following sftp task with mask *.csv hat the output (error):
Exception in Task: No file(s) uploaded

I triggered all tasks manually one-by-one this morning, everything went fine. I activated "Extended Task debug logging", hopefully I see more details in the logfile, but all jobs are writing in the same file and dont have any job-id in the lines. Is there any further logging possibility?

Regards,
Martin

It seems to be some flow-related issue making it so that the file(s) do not exist at the exact moment it's going to upload. It would help if you exported the job and sent it to support@visualcron.com unless you find the issue yourself with the extended log debugging. Currently, that's the only in-depth logging we have within the software.

---

Hello Michael,
this morning I found the solution. A n other job has got a typo in the path and is running same time. This job is archiving all data and deleting it afterwards. And this job is sometimes faster than the original.

It was a layer 8 problem. -> closed.

Kind regards, Martin

Hello Michael,
this morning I found the solution. A n other job has got a typo in the path and is running same time. This job is archiving all data and deleting it afterwards. And this job is sometimes faster than the original.

It was a layer 8 problem. -> closed.

Kind regards, Martin

Ah yes. Glad you found it. Problems like that can be tricky and time-consuming for us to solve/catch sometimes :)

---