Attribute table OBJECTID skip number? see screenshot

[AlexP_]

Hi,

When I deleted a row data on Attribute table and I noticed on OBJECTEDID a number skipped when I create another new one. See screenshot. Is there anyway to fix? Please advise. 

[DanPatterson_Retired]

Try saving your edits, close the table, save your project and check again.. If that doesn't work. close the project after saving and reload it

[VinceAngelo]

This is expected behavior.  The objectid column is fed by an increasing value (the exact technique depends on the data source type).  You cannot change the objectid field, and really ought not use it for any purpose (except as a rowid column).

- V

[AlexP_]

Is there any other way to avoid that? Do you have any recommend?

[Asrujit_SenGupta]

Why do you want to avoid this?

As Vince mentioned, this is an expected behavior of the software.

[VinceAngelo · Accepted solution]

Again, it depends on the data source (which you haven't specified).  Dropping and reloading always works. Truncating and reloading often works.  Since the value shouldn't be used for any purpose, the techniques are somewhat moot, and mostly a waste of time/effort.

- V

[JoshuaBixby]

As Vince already suggested, you really should not try to manipulate system-managed fields, doing so risks corrupting the entire data set sooner or later.

Why does it matter that ObjectID 2 is gone and not reused?  What meaning have you placed on the ObjectID field?

[AlexP_]

I wasn't sure and wasn't familiar with data OBJECTID part. Thank you for clarify!

[mikeking1]

The short answer is there is no way to achieve this without creating a new table.  As others have mentioned OBJECTID is a system column and while its extremely useful as an ID column when you need a sequential ID it will only work until you delete a feature.  OBJECTID always starts from the last value in the table (including the values of rows that have been deleted) since the latest value of OBJECTID is stored in a related system table.  This has some serious implications for SDE data but for file gdb its more just annoying.  The has the unfortunate side affect of this design means that any simple attempt to create a sequential ID (like a field calculation) based of OBJECTID will also be non-sequential.  Your options are:

• write to a new feature class/table where upon OBJECTID will automatically be rebuilt for the new table in the sequence they are entered
• write a script that uses an independent record count to populate the sequence as you loop through the table with a cursor.
• use a GLOB or other ID that doesn't require a neat sequence.

Hope that helps!