I have a lingering question that I have not found definitive info on.
Can you have Duplicate Global IDs in a Database? I know that Global IDs are assigned on the Feature Class level but could 2 different FCs have the same Global ID in the same Database?
Solved! Go to Solution.
It is not possible that two features (in different Feature Classes) in the same geodatabase can have the same GlobalID. GlobalIDs uniquely identify a feature or table row in a geodatabase and across geodatabases.
Add Global IDs (Data Management) - https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/add-global-ids.htm
It is not possible that two features (in different Feature Classes) in the same geodatabase can have the same GlobalID. GlobalIDs uniquely identify a feature or table row in a geodatabase and across geodatabases.
Add Global IDs (Data Management) - https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/add-global-ids.htm
Thanks.... I was assuming this... but wanted to be absolutely sure....
So an enterprise DB with 10 different Feature Datasets and say 10-20 Feature Classes per Dataset, with and without Attachments will never have a duplicate Global ID.
Correct. GlobalIDs are a field of type UUID (Universal Unique Identifier).
Universally unique identifier
https://en.wikipedia.org/wiki/Universally_unique_identifier
The probability of collisions (duplicate UUIDs or GlobalIDs) is infinitesimal.
It is possible to get duplicate Global IDs within a geodatabase if you're trying to do so:
The model used to construct UUIDs makes for low likelihood of collisions, though it's higher (but still very unlikely) if you use several different generators (e.g., Oracle and PostgreSQL and Python and Java).
Unfortunately, that very uniqueness makes UUIDs an awful column to drive joins upon (they're modelled as 38-char strings which fragment the available key space).
64-bit integers are coming to Pro in the near future; these would also not be limited to "only" a 4-billion value key space (as 32-bit integers), but would have better join performance for sequential features.
- V