OBJECTID values in Oracle

4001
3
Jump to solution
02-24-2016 07:14 AM
AndrewRudin
Deactivated User

Where do OBJECTID values on a feature class in Oracle come from when inserts occur?  Is it a sequence somewhere, or does ArcMap scan to find the current maximum ID and do a +1 operation before the insert?  In my situation the feature class is versioned and uses ST Geometry.

The feature class also has archiving enabled, so does the GDB_ARCHIVE_OID value on the archive table use the same mechanism to create OBJECTID values when records are inserted there when edits are posted to default?

0 Kudos
1 Solution

Accepted Solutions
by Anonymous User
Not applicable

Dear Andrew

I am not sure but I think that each layer/table registered with the geodabase has its own Oracle sequence for obtaining the OID value. Sequences are named "RXXX" where XXX is the value of the REGISTRATION_ID field related with an specific table/layer in the SDE table TABLE_REGISTRY .

Regards

Jesús de Diego

View solution in original post

0 Kudos
3 Replies
by Anonymous User
Not applicable

Dear Andrew

I am not sure but I think that each layer/table registered with the geodabase has its own Oracle sequence for obtaining the OID value. Sequences are named "RXXX" where XXX is the value of the REGISTRATION_ID field related with an specific table/layer in the SDE table TABLE_REGISTRY .

Regards

Jesús de Diego

0 Kudos
George_Thompson
Esri Notable Contributor

Look at the MINIMUM_ID field in the TABLE_REGISTRY

System tables of a geodatabase stored in Oracle—Help | ArcGIS for Desktop

-George

--- George T.
0 Kudos
VinceAngelo
Esri Esteemed Contributor

It's a bit more complicated than just a sequence, because sequence generation is too slow for bulk insert processes.  Instead, the sequence has an interval (size dependent on version) for a gap in values and a pipe is used to store the next value when a cursor is shut down.  When the next cursor comes along, it will fetch off the pipe before consulting the sequence, to prevent a gap.  If you shut down the instance, the DBMS_PIPE objects are lost, resulting in a gap in subsequent inserts (though there is a [somewhat elderly] KB document that addresses a workaround).

- V

0 Kudos