We are trying to figure out how to keep track of Unique IDs on multiple featureclasses in a versioned environment with an Oracle database. We have looked at using the Attribute Assistant, which would work, but we also have users who edit in the field using Collector and Geocortex applications, and the attribute assistant only works on desktop. I'm sure we aren't the only people with this issue.
Does anyone have ideas on how to solve this.
Frank Goehner
Town of Oakville
I don't have an automated solution, so if someone posts one I would be interested in hearing about it. Here at the City I work for my group has 4 GIS folks who edit the thirty-odd layers we have with manually-generated Unique ID's, so this issue has come up quite a bit. We often have two or more people working on Versions of the same layer and on top of that some of us have more than one Version of that layer also (example: several subdivision projects being entered).
What we have settled for is a plain old Tracking "spreadsheet" table in Word where users note each "range" of unique ID's they are taking for each Unique ID for each feature class in each of their Version(s) so we don't inadvertantly duplicate unique IDs.
One potential solution we have looked at is to use system-generated Global ID's. However, we have several non-GIS systems tied to SDE that don't find Global ID's appetizing, so have stuck for now with our own unique IDs. Also, be aware that dumping out feature classes with a Global ID to a File Geodatabase will cause the Global IDs in the FGDB to be different than what they were in SDE, so one has to keep that in mind.
GlobalID | Definition - Esri Support GIS Dictionary
Chris Donohue, GISP
Using AA in a versioned database has its own set of issues with respect to unique ids. There are a couple threads you might find with a search that discuss the topic. Are you wanting to persist the same unique id between different feature classes for relational purposes? That might be a tall order to fill.
I only use global ids for replication, as Chris mentions they go south in a big way in a big hurry outside of the original database. One thing I do is use the value of the OID in a separate field. That way the uniqueness is taken care of, and the values in that extra field remain in tact if you migrate to another database. I wish I gad a more solud solution to offer.