Trigger on Versioned Geodatabase

3825
10
Jump to solution
03-23-2016 03:32 PM
Highlighted
Occasional Contributor II


I am trying to create a trigger on a versioned geodatabase, I created the trigger before registering the GDB as versioned; it worked well. However, when registering it as versioned GDB, the trigger does not work, and I am not able to create a trigger on the _evw view.

Is their a way to attach a trigger to the versioned GDB that is immediately fired when inserting/updating features?

Any help is appreciated!

Hani

1 Solution

Accepted Solutions
Highlighted
Esri Esteemed Contributor

Triggers aren't encouraged when intermixing with geodatabase functionality, but can work if you put them in the right place.  For versioned inserts, that place is not the business table, but instead on the ADDs table.  Both insert and update requests go through the ADDs table first, so there is no reason to place a trigger on the business table (which would only fire during reconcile/post) .

View solution in original post

10 Replies
Highlighted
Esri Esteemed Contributor

Triggers aren't encouraged when intermixing with geodatabase functionality, but can work if you put them in the right place.  For versioned inserts, that place is not the business table, but instead on the ADDs table.  Both insert and update requests go through the ADDs table first, so there is no reason to place a trigger on the business table (which would only fire during reconcile/post) .

View solution in original post

Highlighted
Occasional Contributor II

Many Thanks Vince!

As usual, your solutions resolve my issues!

Reply
0 Kudos
Highlighted
Occasional Contributor II

BTW, Why the triggers are not recommended in geodatabases? What GDB capabilities/functions could be affected?

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor
What GDB capabilities/functions could be affected?

All of them. Like any powerful tool, triggers could corrupt your geodatabase quite effectively (albeit unintentionally) -- corrupting versioning, altering domains, mangling relationship classes, ...  the list is endless, really.  Extreme caution  is recommended.

- V

Highlighted
New Contributor II

Hi Vince,

I'm creating an easy trigger for data validation on a test feature class in a 10.3.1 SDE environment. We have an Oracle 11g backend as well.

However, I find that when editing the data in ArcMap, no matter what I'm doing, it only fires the Insert Trigger.

So, if I edit a feature that already exists, instead of the Update trigger running, the Insert Trigger runs. If I add a new record, then the Insert Trigger runs as its supposed to.

Wonder if you've encountered this.

Thanks,

Ruchira

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

Yes, this is the expected behavior.  There is no such thing as an UPDATE or DELETE in the versioning model, only a pair of INSERTs (one to the adds table, the other to deletes) and a single INSERT to deletes.  If you play close attention to how versioning is implemented, you'll understand why use of triggers is discouraged.

- V

Reply
0 Kudos
Highlighted
New Contributor II

Ah, I get it! Thanks for clearing that up. Everything, whether an attribute update, add, or delete is an INSERT on the A and D table.

I've noticed however that when working with feature services, it is an update statement that runs to commit the attributes to the table. The record geometry is inserted, but it's an update that inputs the data into the newly created record.

Thanks,

Ruch

Highlighted
New Contributor III

Thank you for pointing out the INSERT/UPDATE process Ruch.  It was driving me crazy, because my INSERT trigger works great in ArcMap, but fails on the feature service.  Have you developed a consistent process to handle this behavior?

Reply
0 Kudos
Highlighted
Occasional Contributor II

Hi Ruchira

Maybe, in order to maintain the lineage inside each version... any edition on a feature is treated as a insert....If you update the feature this lineage is lost. Does this make sense?

Regards

Jesús de Diego

Reply
0 Kudos