Attribute Rules not Triggered by SQL Transaction

02-12-2021 05:49 AM
Occasional Contributor II

We're having some trouble with a process that bridges Cityworks and ArcGIS. We have a field in our vehicles/fleet table in GIS that stores the mileage to the next service, which has an attribute rule to keep the value updated. This updates just fine when my Python script pulls in the current mileages from our gas cards, but we noticed it doesn't update when the last service mileage is updated. The difference here is that our Cityworks consultants set up a db trigger that writes that value to the fleet table using a SQL statement. It seems like Esri doesn't recognize this as an edit, as the last edit date and last editor fields don't update.

I think I can resolve this either by setting up a deferred evaluation rule and scheduling that to run periodically, or by periodically re-writing the existing values to the last service mileage field using an update cursor to create an Esri recognized edit. The problem with #1 is I need to set up branch versioning and I'm not sure we're ready for that quite yet. #2 seems inelegant. Are there any other ways to make this work? It would be great if there was a way for Esri to recognize the SQL-triggered update.

0 Kudos
2 Replies
Esri Esteemed Contributor

No, Esri libraries are not going to update the database tables when they aren't used.

You'd need to write your SQL trigger to also update the last_editor and last_update.

Getting triggers to play nice with versioning seems an opportunity for "bleeding edge" experimentation.

- V

Occasional Contributor II

Thanks for the confirmation. The SQL triggers are outside of my control, so I'll have to tinker around on the Python side to find something that's not too clunky.

0 Kudos