We're running adTempus 4.1 and experiencing this issue:
CR00004088
File Trigger may not trigger for files on network drives
We understand that it's fixed in version 4.3 but might be interested more in a hotfix that we can apply.
Is there one available.?
Thanks.
Ken
We only do cumulative hotfix builds, based on the most recent release. This issue was fixed after 4.2, so to get the fix you would need to update to 4.2 and then apply the hotfix build that contains this fix plus a few others. If you want to do that, please open a support case to get the hotfix.
Otherwise you should just install the latest version (4.4).
Couple of related questions, Bill.
I can upgrade directly from version 4.1 to 4.4, correct?
Also, if I have server that has multiple instances, do I do the install once, or once for each instance?
And when I upgrade, the license will stay intact and I won't have to do anything related to licensing?
Oops, there is one database update you would need to run if you downgrade from 4.4 to an earlier version. The 4.4 upgrade adds a new index and updates the schema version, which causes 4.3 and earlier to complain.
To solve it you would run this database query:
update options set optionvalue='409' where optionName='dbVersion'
See here for instructions on updating the database.
You can do this before you remove 4.4, or after you install 4.1 (the adTempus service will fail to start; at that point you can go do the update and then restart it).
The index remains in the database, which is fine. If you subsequently upgrade to 4.4 or later, there won't be any problems.
Hi Bill,
We've upgraded to adTempus 4.4 on our server, but still running into the job not triggering when a file is dropped into the folder.
Have you had any other users experiencing this?
Any help would be appreciated as this is a feature we just for a number of jobs in our production environment.
Ken
There are no other known issues with file triggers.
Is it always not working or only sometimes?
If it's never working then it's probably a configuration problem.
Otherwise you should turn on diagnostic logging for the adTempus service and repeat your test. You can open a support case and have us review the log to see what's going on, you can try to interpret it yourself. If you search for the name of the file you're expecting it to trigger on, you can see when it detects the file and what action it takes.
How does the file trigger work?
Maybe I'm confusing it with the idea of a file listener. With a file listener, I can take any file (regardless of when it was created or last modified), and drop it into a folder, the file listener will identify it and process it.
Let's say the polling interval was set to 5 minutes.
If I created a file 10 minutes ago and saved it on my local folder, waited 6 minutes, then copied the file into the File Trigger location, I don't think the adTempus File Trigger would process with file because the create date is NOT within the last 5 minutes.
I'm noticing that if I create the file in the adTempus File Trigger location (network location), it's still not triggering. If I delete the file, and recreate the same file (using notepad), the create date reflects the create date of the earlier file. This is odd.
Now, if I check-mark the "Trigger when file is modified" adTempus option, leave the file in the network location, and make small edit to the file so the modified date is changed, the trigger works and the job is fired.
For me, the file modified trigger works, but I'm still having a problem with getting the "Trigger when file is created" option to work.
Any thoughts on this one?
It looks like when you update the file location, the Trigger Status option is not updated.
In order to update the Trigger Status, you have to delete the trigger, and then add the new trigger.
You can't just update the file name in the trigger via the edit trigger button. The Trigger Status doesn't get updated.
The File Trigger does function as a listener, but it does this by polling the target folder. On each pass, it makes a list of the files in the folder and compares the list to the previous pass. Any file in the folder that was not there on the previous pass is seen as a new file, regardless of its timestamp. Any file that was there on the previous pass but has a newer timestamp is seen as a change. Any file that was there on the previous pass but not now is seen as a deletion.
If you delete a file and recreate it within the polling interval, this is seen as a change, because the file was there before, and it's there now with a different timestamp. So it you're testing with the same file all the time, you may not be waiting long enough after you remove the file for adTempus to see that it's gone and therefore be able to recognize it as new when you put it back.
Also note that the first pass after you create the trigger (or after you change the filespec) it's establishing the baseline snapshot of the folder, and therefore won't trigger for any files. So if you create the trigger and then go create a file in the folder before it's had time to complete the first pass, it's not going to treat this as a creation.
If you're seeing the creation timestamp not change in Windows, that could be due to caching. See here, for example. But again, adTempus doesn't care about the creation timestamp. It only cares if the file was there on the last pass or not, and if so, whether the last modification timestamp has changed.
I confirmed the problem you're seeing with the filespec in the Trigger Status window. However, this is only affecting the display in the status window; the trigger correctly uses the new filespec.
Replies are disabled for this topic.
Staff