ObjectID of an ArcSDE feature class skipping values

4392
8
10-31-2011 11:50 AM
JonathanHouck
New Contributor III
Hello everyone,

I'm running ArcSDE 10 SP1 with Microsoft SQL Server 2008 R2.

I've got some strange behavior in one of our utility feature classes.  It's participating in a feature dataset, and when my editors create new features, the ObjectID they're getting assigned is out of sequence.  For example, the first thirteen features all had objectID's of 1-13, but the fourteenth had an objectID of 413, and the fifteenth had an objectID of 813.  It goes up by 400 each new feature.  We had a similar problem with another feature class, except it would be two successive numbers before the big jump in ObjectID (412, 413, 812, 813, etc).  This was fixed by exporting the feature class and bringing it back in so the ObjectID's were reassigned in the new feature class.  Since this seems to be recurring at this point, I really want to know what's going on.

This hasn't caused any immediate problems but I'm curious if anyone knows what could be causing this behavior?  I find it unsettling at the very least, and want to make sure it's not a symptom of a greater problem.

Thank you!
8 Replies
VinceAngelo
Esri Esteemed Contributor

SDE-set objectid values are managed by a sequence (or on SQL-Server, by one-row table
that is incremented).  It is very inefficient to increment with each row, so ArcSDE actually
increments by a larger value (200 or 400) and assigns the values in between by itself.
On Oracle, the excess values are stuffed in a DBMS_PIPE for re-use; I'm not positive that
an equivalent exists with Microsoft.  In the end it doesn't really matter, since the values
only need to be unique (and positive) for the linkage between tables and graphics within
ArcGIS (it's not an error, just an implementation quirk of the load process).

- V

AdrienHafner
Occasional Contributor

Hi Vince, 

I'm experiencing the same issue on a couple of datasets using MSSQL Server.   My questions are a) why doesn't this sequencing occur in every feature class? and b) is there any way to remedy/avoid it?

Thanks!

Adrien 

0 Kudos
VinceAngelo
Esri Esteemed Contributor

As described elsewhere in this thread, it's an artifact of how features are loaded, and there's no way to externally influence the behavior. It's not hurting anything, so it does not seem to need remedy.

- V

0 Kudos
AdrienHafner
Occasional Contributor

Hi Vince,

Good morning, and thank you for your response.  I've read this thread in great detail, and what I'm not seeing, which is why I asked the question, is why this behavior occurs with only a small percentage of feature classes and not all of them?  What about the feature class and its loading procedure causes some to behave 'normally' and others to skip by 200 or 400?  Again, I understand your explanation as to why it skips, but I don't understand why it's not consistent among all feature classes in existence in the world.  Secondly, the reason I'm asking about a solution is because a) it looks messy and b) it will cause our dataset to reach the maximum number allowable prematurely.

Thanks,

Adrien  

0 Kudos
VinceAngelo
Esri Esteemed Contributor

I have no idea why any one particular layer would have skipped values (besides when using multiple appends and/or multiple simultaneous inserts). The visibility of messiness is questionable, since these IDs are not intended for any other use. You should not ever exceed 20-50 million rows in any table, so reaching the 2^31-1 rowid limit first seems like quite a challenge.

If you want to discover why your your site is exhibiting this specific behavior, please open a Tech Support ticket. They have better means to reproduce this issue than I do.

- V

0 Kudos
JohnCalgiano
New Contributor
vangelo,

We are having the same issue in the current version of SDE. How do we manage the SDE sequenced values in Arc? Thank you.

John
0 Kudos
VinceAngelo
Esri Esteemed Contributor
You can't manage SDE sequenced values.  "SDE-set" is exactly that.
Best practice is to avoid using registered rowid values for any other
purpose, so this shouldn't even be an issue.

- V
0 Kudos
JohnCalgiano
New Contributor
OK, Thank you for the quick response.

John
0 Kudos