Commander Printing file based trigger twice Follow
We have been using Commander for several years have use a file based trigger file. Recently, we added a new type of label that pulls a number of fields and requests typically contain more than our usual number of rows. I am seeing that there are occurrences of these files being printed twice. I can confirm there will be only 1 trigger file - but using Reprint Console, I see the labels printed in two sets. I found that the create date/time on these files is a few seconds before the modified date - so my theory is that these files take longer to write and Commander is picking up the file before it is completed written.
A couple other misc items - I have 3 tasks running in Commander, polling for trigger files every 60 seconds. When this happens, it is always with these newer label formats (that I have heard). These pull more data from the database to produce these trigger files so I can see where these may take slightly longer to create. This does not happen all the time - I suspect it happens only when the file started to be created when the directory is polled but finishes getting created before the next polling.
Our application is set up to be able to create smaller files for a large number of rows - that limit is currently set for 500 - meaning, any requests resulting in more than 500 labels will result in multiple files - each with a 'chunk' of the request. Years ago when I set this up, I purposely kept this number high - because my users did not like the chunks printing out of order (if the printer has a queue and the current request is for 600 labels, the first 500 will be written to one trigger file, the other 100 to another - but the 100 will print first as the printer will often take smaller jobs rather than larger ones when there is a queue).
I am using Brady printers with Seagull drivers. I am using Enterprise Automation version 10.0 SR4. We have an upgrade planned but I cannot wait with this issue.
Is there any way to tell Commander not to take a trigger file if it is still being written? Or, is there a way I can tell the printers to print the jobs in the order they are sent?