Skip to main content
  • EN
  • Home
  • Forums
  • FME Form
  • General
  • Directory watch on an access database does not trigger the FME server cause there is no change in file size

I have an access database that gets updated when data is checked in from a mobile device.

which is set up as a FME Server workspace with directory watch protocol set to modify . I was hoping that adding new records would change the file size and the workspace gets triggered which in-turn triggers a child workspace. Unfortunately the size does not change every time data gets checked-in.

Im looking for help on how to check for updated records in an access database since the SQL executor doesn't work on access database.

The access database has valve exercising information ,which is used to create inspections in cityworks using the Cityworks API. The child workspace uses the API to make the API calls to Cityworks.

As a workaround in access you can create a "data macro" and call a "comand shell" to edit a log file. The directory watch will fire on the changes of this log file. You can follow the two links below:

https://support.office.com/en-us/article/create-a-data-macro-b1b94bca-4f17-47ad-a66d-f296ef834200?ocmsassetID=HA010378170&CorrelationId=04012b3a-5288-4827-ab0d-77b776e21499&ui=en-US&rs=en-US&ad=US

https://support.office.com/en-us/article/shell-function-ff2e4b1b-712d-4e34-aea6-6832eadd3c63

 

As a workaround in access you can create a "data macro" and call a "comand shell" to edit a log file. The directory watch will fire on the changes of this log file. You can follow the two links below:

https://support.office.com/en-us/article/create-a-data-macro-b1b94bca-4f17-47ad-a66d-f296ef834200?ocmsassetID=HA010378170&CorrelationId=04012b3a-5288-4827-ab0d-77b776e21499&ui=en-US&rs=en-US&ad=US

https://support.office.com/en-us/article/shell-function-ff2e4b1b-712d-4e34-aea6-6832eadd3c63

 

This isn't a valid workaround for my situation ,becuase the access database is infact a vitals .vcd file that can be opened by access ,but all options for Before Events and AfterEvents are greyed out.

Sadly that's a known issue with the directory watch. I'm a little surprised it's based on file size, but that does seem to be the case. It's filed as FMESERVER-7931 with our developers, but I don't believe there is an update imminent. The only workaround I can think of it to delete and rewrite the file, instead of updating, which probably isn't an attractive option. But I really can't think of another way.

While this may not be ideal you could have a scheduled job with a Directory and File Pathnames Reader to check the modified date before terminating or processing the data. Since its a quick read if nothing has changed it shouldn't eat up too many resources.

While this may not be ideal you could have a scheduled job with a Directory and File Pathnames Reader to check the modified date before terminating or processing the data. Since its a quick read if nothing has changed it shouldn't eat up too many resources.

Hello @richardatsafe,

This is definitely a great alternative ,Im going give this a try !!

Sadly that's a known issue with the directory watch. I'm a little surprised it's based on file size, but that does seem to be the case. It's filed as FMESERVER-7931 with our developers, but I don't believe there is an update imminent. The only workaround I can think of it to delete and rewrite the file, instead of updating, which probably isn't an attractive option. But I really can't think of another way.

Hello @mark2atsafe,

It definitely is on file size ,cause when I manually compress and repair the database in access the file size changes and the process gets triggered. Im trying different ways to get at it .

Appreciate your response.

Sadly that's a known issue with the directory watch. I'm a little surprised it's based on file size, but that does seem to be the case. It's filed as FMESERVER-7931 with our developers, but I don't believe there is an update imminent. The only workaround I can think of it to delete and rewrite the file, instead of updating, which probably isn't an attractive option. But I really can't think of another way.

Hi @mark2atsafe. What is the status of this issue? We are having the same problem and I can confirm that the FME Server directory watcher only seems to look at the filesize and not the change date of a given file.

 

We are watching files where users only modify a date. This date is allways in the same format and therefore the directory watcher ist not detecting any changes.

Thank you for your update.

Hi @mark2atsafe. What is the status of this issue? We are having the same problem and I can confirm that the FME Server directory watcher only seems to look at the filesize and not the change date of a given file.

 

We are watching files where users only modify a date. This date is allways in the same format and therefore the directory watcher ist not detecting any changes.

Thank you for your update.

Hi @simon11

Well I've added your details to the issue so that you are contacted if and when it is fixed, and adding an extra user report should increase the priority somewhat. However, I still don't see that it's as high a priority as other issues. I'm sorry about that. I'll do my best to push things along, but all I can really suggest for you is to contact your local partner/reseller and try to put together a business case why it should get a higher priority. If a shortcoming is seriously affecting a user's workflow we try to implement it quicker.

@adi and @simon11 We recently made some changes to the Directory Watch protocol in FME Server so that it will also check the timestamp (and not just file size). It will now trigger a MODIFY event if the file size does not change, but the timestamp does.

This is available for testing in the latest FME Server 2020.0 betas – please use build 20169 or newer.

Reply


Community Stats

30,162
Posts
114,482
Replies
37,809
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.