I have a List Files task that pulls the full file name(s) of all files in a folder. I am using the tilde as the file separator.

I then create a loop, using the for x to y format, where x starts at 1 and y is the Result.Norows of the List Files task.

In a test job, where the only function in the loop is to a) pop up the name of the current file in the list, and b) move that file to an archive folder, every thing works fine and wonderful, and no matter how many files are in the folder, everyone of them is successfully listed in the pop-up and moved to the archive folder.

When I duplicate that in a production job, the loop finds the first file, performs the 4 tasks needed with the file, and then stops. It never goes beyond the first file it finds in the tilde delimited List Files OutPut.

I have checked and rechecked to verify that my production job is using the same delimiters, and functions to split out the desired file name, and they are all the same, but the test job handles all the files in the folder, while the production job only handles the first file and then quits.

What else should I be looking at to explain this oddness?

Version 8.2.4

thanks
Luther

Just a comment that for this type of processing I do it differently. Maybe try it and see if it works. Sorry but I have no suggestions for your situation that you haven't already tried I'm sure.
- List file and output separator is CrLf. This leaves the task's STDOUT as a list of files in a column
- loop is "For each x in y, with the source as the previous task's Stdout but use the list files task's directID. Use column: 0
Field sep: Tab
Text qual: blank
Line break: CrLf
Start row: 1
Check to validate values when saving

Let us know what happens.

I've done stuff like this the same way Gary_W has, using a "For each X in Y" loop, and never run into this issue. I would suggest trying that, as it seems (at least to me) to be a cleaner way of doing this. I suppose the advantage of using a "for X = 1 to Y" is that you'd have a built in counter for the files, but that's only an advantage if you need a counter.

When you say "duplicate that in a production job", how are you duplicating it? I've found that when I clone a job, it doesn't update the references to the various task ID's within the job, so what I end up with is a second job that refers to tasks in the first job. I'm wondering if something like that is happening here - your NoRows variable refers to the result from your non-production job. Just a thought of something to check, if you haven't already. Or maybe it's not even relevant, because it depends on how you duplicated the job.