topic Re: Static Versions for Change Detection in the UN in Electric Questions

Static Versions for Change Detection in the UN

EdwardBlair — Fri, 17 Apr 2026 20:27:30 GMT

Hi all -

In our current implementation use use several "static" versions to assist with Geodatabase change detection. For example, there is a nightly process that compares a static version with SDE.Default to determine which feeders have changed in order to inform the OMS interface which feeders need to be extracted and updated in the OMS database.

There are other static versions for other, somewhat similar purposes.

For OMS we might be using ArcFM GDBM/Feeder Services to detect changes. But for other, non-feeder change purposes, we're wondering if we need to keep static versions around.

Any thoughts/experiences on this would be much appreciated.

Thanks,

Re: Static Versions for Change Detection in the UN

EdwardBlair — Fri, 17 Apr 2026 21:23:26 GMT

... as a follow-up, and possibly clarify this question, we currently get differences between versions by using "version difference" queries.. mostly in FME. These things detect changes by looking at rows in the versioning A and D tables. With branch versioning there are no longer A and D tables, rather there are "born on" and "died on" date fields.

So... to find out what has changed over the past period of time, will we request version differences? (and then reconcile when we're done.) Or will we perform "date difference" queries on the branch versioning classes?

Re: Static Versions for Change Detection in the UN

gis_KIWI4 — Sun, 19 Apr 2026 21:59:44 GMT

@EdwardBlair - The are few different implementation patterns here.
The one you have highlighted works but maybe you don't need to have static versions if you the below were acceptable to your use case.
=====================================================

The ExportSubnetwork REST API supports "moment" parameter which lets you export the subnetwork as of a given time.
https://developers.arcgis.com/rest/services-reference/enterprise/exportsubnetwork-utility-network-server/

So maybe you could do a call to get current and a historic version -> compare and decide if you want to send this update to OMS.

This way gives you the flexibility to ignore the update if it's not meaningful example only one vertex has changed in the subnetwork then don't send to OMS. But if you new customers are added then send to the OMS.

Another way is using the LASTUPDATESUBNETWORK and LASTACKEXPORTSUBNETWORK fields. If the LASTUPDATESUBNETWORK is greater than LASTACKEXPORTSUBNETWORK then something has changed since the last export and you'd want to check this subnetwork for changes.

You can do this quite easily within FME and use something like JSONFragmenter and JSONQuery to view and analyze the results.

Re: Static Versions for Change Detection in the UN

EdwardBlair — Mon, 20 Apr 2026 15:02:33 GMT

Hi @gis_KIWI4 ... thanks much for the feedback.

I should have been clearer. For subnetwork change detection we *hope to* use the SE GDBM framework.

Thing is, we also need to detect changes to other, non-Utility Network feature classes. This is, at the moment, what I'm most interested in.

Re: Static Versions for Change Detection in the UN

gis_KIWI4 — Mon, 20 Apr 2026 22:53:09 GMT

@EdwardBlair - I am assuming your non-UN feature classes have versioned data. You can continue using static copies to get version differences but if you didn't want to keep the static copies then use the ExtractChanges or Query(with Historic Moment) or simply using the EditDate query?

Each one comes with it's own set of advantages and disadvantages.

ExtractChanges - Most robust and gives you the "delta" so you don't have to find differences within a FME process. This is slightly more complex to implement because you have to store generation states (layerservergens) and use them for the next query.

Query(with Historic Moment) - Simple but you have to read the entire dataset twice (current and historic) and then set up change detection. If the dataset is sizable then you risk running the process longer.

EditDate query - Simplest of the lot but you have to figure out how you will account for deletes.

Our datasets are pretty modest in size and we have used Query with the FME CHANGEDETECTOR transformer.

Re: Static Versions for Change Detection in the UN

EdwardBlair — Tue, 21 Apr 2026 12:35:14 GMT

@gis_KIWI4 Pretty interesting. Thanks much for the detail. We will check out these options!