I am attempting to set up some event triggers, and am encountering several problems.

1) One problem that I have had with triggers is that sometimes triggers don't accept changes, and have to be deleted and recreated. So I typically don't use triggers that are a part of a cloned job, if I need to make modifications - I delete and recreate triggers for each job, so I can be certain that it is set the way that I intended.

2) Now, on some of these triggers, that have been created fresh for a job that was cloned from another job, I am getting the error message: "Could not find associated job for event: <Trigger Description>", when I go into the job to make modifications.

3) When using event triggers based on a file being created, I have encountered problems with the job running more than once for the same file (which is very undesirable.) That was a while ago, and I no longer have the details on how the job was set up, but there was nothing in the configuration that I would have anticipated causing it to run multiple times. However, more recently, the problem is that the job, based on a file event trigger, will run once, but it won't run the next day without manual intervention.

I'd like to use a file event trigger to run a job to FTP deliver the file at the moment it appears in the folder. This is typically once every ~24 hours (there is some time variance, which makes the event trigger more desirable than a time trigger), either 5 or 7 days a week. It's important for the job to not run a second time, once it has picked up a particular file; it's also important for it to run when the next day's file appears.

Could you provide some assistance in properly using the event trigger?

1. What kind of Triggers are you talking about? File Trigger.
2. We will test this when we know the Trigger type.
3. The problem is probably that you use the Change instead of Created. Change do fire multiple times as a change can be many events (combinations of modify/delete/rename).

---

1. The problem with the trigger not accepting changes is particular to time triggers. The case that I have seen it most often is when cloning a job, I often need to modify the time trigger in the new job. I will make and save the change, but if I recheck my work, I find that it still has the old information in it, and it persists even after several attempted changes. Another interesting aspect to this, is that appears to be more likely when cloning a job that has not been cloned before. If I clone the same job over and over again, then the cloned jobs appear to be ok with accepting modifications to the time trigger.

2. For the file event trigger that fired multiple times, unfortunately, I no longer have that job configuration to refer back to for many details on that - it's still a little concerning though, to not know what caused the problem, since that is a major problem if a file is sent multiple times. I think it was set up as "created", but it's possible that "change" could have been used - hopefully that explains it.

3. For the file event trigger that doesn't see the file the next day, that involves a current configuration that isn't working. (We mostly have time triggers set up right now - but we'd really like to move to file event triggers, but are encountering difficulties with getting them to work.) Of the issues mentioned, that is the most pressing at the moment.

4. Another issue, just observed, is that with the file event trigger, in the cloned job, does not seem to function at all; similar to the time trigger, it needs to be recreated fresh sometimes in a cloned job.

I recently got the file event trigger to work after midnight; hopefully that issue is resolved. But immediately encountered something new.

Before midnight, I dropped a file (which uses a date variable for the current day's date in the filename) in the watched folder, and triggered the job in question, and it ran successfully.

After midnight, I dropped a file with the new current date in the watched folder - and the file event trigger fired. However, the job failed. When looking at the logs what I saw was that some of the variables were showing the previous day's date in the log (0503 being the current date in question.)

For example, at the File Trigger Event, I see this:

5/3/2008 12:08:55 AM Debug File trigger event (objectchanged): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Debug File trigger event (enter lock): 1, path: \servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Debug File trigger event (before counter check): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Debug File trigger event (in counter check): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Debug File trigger event (result object created): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Debug File trigger event (after file release): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt

The date variable is showing the previous day's date, the file actually had the current day's date - and the trigger fired?

Then, this is the log of the first task - it still shows the previous day's date in the file name; it did not successfully copy the file, the output was "no output" and the result was "successful".

5/3/2008 12:08:55 AM Debug Task (1362) was added to processlist: Move 13 file to remote test
5/3/2008 12:08:55 AM Debug File trigger event (before sending result): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Info Task started: Move 13 file to remote test
5/3/2008 12:08:55 AM Debug File trigger event (after sending result): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Debug File trigger event (exit lock): 1, path: \\servername\m$\FileStore\Messaging0502134500.txt
5/3/2008 12:08:55 AM Info Task completed: Move 13 file to remote test
5/3/2008 12:08:55 AM Debug Setting previous task in TaskProcessCompleted: Move 13 file to remote test (2f929106-ca41-414e-af0a-33e95dadfd67) in job: --TEST--

The second task is an encryption task, which failed, since the file had not been moved in the first task. Note this time, though, the date variable is showing the current day's date as expected.

5/3/2008 12:08:57 AM Err PGP File encryption error: Could not find file '\\servername\m$\FileStore\Messaging0503134500.txt'

Please post the variable that you are using.

---

The filename, in the file event trigger, and all tasks in the job, is set up like this:

Messaging{DATEFORMAT(MMdd)}134500.txt (the time in the filename is always a constant, rather than the exact minute/second the file generates, which may vary a bit.)

So, if the current day is 5/3, I would think I would see in the log Messaging0503134500.txt for every filename reference...but I see some of them show 5/2 (which was the last time the trigger fired, the previous day....I'm assuming that this is why the job failed when it was triggered again on 5/3?)

(Also, in case it makes a difference, the folder being watched is on a remote server.)

It turned out, that the job that triggered after midnight, did not trigger again, so that is still an issue.

A few questions (in addition to the issue raised in the earlier post):

1) I read about the FileSystemWatcher on MSDN; is that what is being used here? If so, one statement was to "Avoid watching files with long file names. Consider renaming using shorter names." Could this possibly be an issue here? My sample file names are truncated in my posts; the full filename we are watching in this case is 34 characters (including the extension.) I am testing with shorter filenames, but would appreciate having a general idea of how long might be too long (or if you even think that this could be the issue at all.)

2) One thing we have noticed is that the file event triggers do work after the job is edited (it just has to be edited each day, or they stop working again.) I also noticed that if I restart the VC server application, I see in the server log that File Watcher was started for each of the jobs with a file event trigger. Is there a way to schedule something in VC that would have the effect of starting File Watcher each day after midnight for each of the jobs that use it? (We have multiple VC servers, so if it is something that could not be done from the same server, but could be done from a remote server, that might work.) Is there a better solution to this problem??? Even if this were possible, it would be a lot of work to implement if we were to use file event triggers extensively.

Correct, we use file system watcher. But the problem is probably that you use a variable in the filename/folder. Variables are not re-evaluated while watched because this would force us to dispose/create the object all the time. But, I think a valid interval for re-evaluating it would be every minute and not too costful.

The problem with re-evaluating is also the reason for the same date as it uses the date when it was added.

---

A fix for this would have a large and very positive impact on our use of Visual Cron. We hope to use file triggers extensively, and most of the watched files/folders involve date variables.

I understand. We will look at that now.

---