CreateRow skipping sequential objectid's on insert

Question

Creating a custom pane addin for editing a table of values.  However, the objectid's of the added values are far off from being the next number. For example, it goes from 405 to 801:

After truncating the table and restarting at 303, it goes to 705, then 1506:

Using the recommended process for creating a row in a table:

try
            {
                EditOperation editOperation = new EditOperation();
                await ArcGIS.Desktop.Framework.Threading.Tasks.QueuedTask.Run(() =>
                {

using (Geodatabase geodatabase = new Geodatabase(new DatabaseConnectionFile(new Uri(App_paths.AsrCntyConnection))))
                    using (Table UnlistedEdit = geodatabase.OpenDataset<Table>("db.sde.unlisted"))
                    {
                        editOperation.Callback(context =>
                        {
                            using (RowBuffer rowBuffer = UnlistedEdit.CreateRowBuffer())
                            {
                                try
                                {
                                    rowBuffer["accountno"] = unlistedaccount.AccountNo;
                                    rowBuffer["name1"] = unlistedaccount.OwnerName;
                                    using (Row row = UnlistedEdit.CreateRow(rowBuffer))
                                    {
                                        // To Indicate that the attribute table has to be updated.
                                        context.Invalidate(row);
                                    }
                                }
                                catch (GeodatabaseException exObj)
                                {
                                    updteResults = false;
                                  System.Diagnostics.Debug.WriteLine($"Failed while inserting account for {unlistedaccount.AccountNo}", exObj);
                                }
                            }
                        }, UnlistedEdit);
                        try
                        {
                            updteResults = editOperation.Execute();
                            if (!updteResults) message = editOperation.ErrorMessage;
                        }
                        catch (GeodatabaseException exObj)
                        {
                            message = exObj.Message;
                        }
                        return updteResults;
                    }
                });
            }
            catch (GeodatabaseFieldException fieldException)
            {
                updteResults = false;
                System.Diagnostics.Debug.WriteLine($"Field Exception while inserting account for {unlistedaccount.AccountNo}", fieldException);
            }
            catch (Exception exception)
            {
                updteResults = false;
                System.Diagnostics.Debug.WriteLine($"Exception while inserting account for {unlistedaccount.AccountNo}", exception);
            }
            return updteResults;

Before reporting this as a bug, anyone else see this behavior/ issue?

VinceAngelo · Answer

ID assignment is quirky, but that's an artifact of needing to work for both a hundred features and a hundred million. If you can deemphasize the significance of the OBJECTID in the eyes of users, it's probably worth the effort.

- V

Anonymous User · Answer

Thanks Vince. The db is Postgres 11. The server/ db instance have not been restarted at all during this and I am the only one testing against it and only one testing the addin.

The table was populated by an append from within catalog (up to 303 and up to the 405 in the pictures) so I have some test data to work with while writing this addin. The couple entries afterwards (801, and the 705, 1506) come from the addin's CreateRow() method as a single insert per transaction.

I wouldn't think that inserting one item needs a reserve block of 700 id's. Is that what the CreateRows() method does? Is there an alternative way to create a row in a table that I can use since it will only insert one row at a time? When the user sees that it goes from 304 to 878, they are going to wonder what happened to 305-877 and if they broke it or not. They'll think something happened and they deleted 305-877.

VinceAngelo · Answer

Some more details would be useful:

* Which RDBMS is being used for the data source?
* Has it been restarted since the last features were loaded?

In general, this is expected behavior.  Sequence-based ID assignment is not very efficient for bulk loading, so ArcGIS uses a sequence (or sequence-like structure) to allocate blocks of IDs. The size of the block is dependent on the ArcGIS release and the RDBMS. In theory, they would be equivalent, but there are use cases where the remainder of the IDs within the block are not allocated completely. And, of course, multiple simultaneous loaders will insert using different ID ranges, so it can be difficult to determine missing ranges.

In practice it doesn't much matter, since the allocated IDs should only really be used by the geodatabase to maintain uniqueness, not for any other purpose.

- V