Trigger on Versioned Geodatabase

[HaniDraidi]

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

[VinceAngelo · Accepted solution]

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) .

[HaniDraidi]

Many Thanks Vince!

As usual, your solutions resolve my issues!

[HaniDraidi]

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

[VinceAngelo]

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

[Anonymous User]

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

[VinceAngelo]

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

[Anonymous User]

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

[SteveSchunzel]

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?

[Anonymous User]

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