I have "Edit" and "Publish" enterprise geodatabases (SQL Server 2014) with a one-way replica from Edit to Publish. Some feature classes are maintained by users with their own copies in other locations (file gdb, .shp) so I have a script that finds updated copies, runs Delete Features / Append to update the Edit geodatabase and then Syncronize Changes to update the Publish geodatabase. This process will not reset the OBJECTID's back to 0, so they will continue to accumulate every time I run the process. I don't know if this will be a problem in the future or not but I don't really like it. Is there a way to get the OBJECTID to reset to 0 in this process without having to unregister the feature class as versioned (to use Truncate), which I think would also require me to re-establish the replica? Running a "compress database" after Delete Features didn't work.
Are you worried that you will run out of ObjectID's to use?
The limit is: 2,147,483,647
What is an ObjectID?—Help | ArcGIS Desktop
They are managed by the enterprise GDB. I am sure that could may be able to reset the sequence, but that may have unintended consequences, especially with replicas.
Update: I found some more links for you to review. The consensus is let if be
FAQ: Why do Object IDs increment by 400 when editing ArcSDE geodatabases?
How To: Alter an ArcSDE row_id sequence in Oracle - Not SQL Server but same principal
Hope these are helpful.
Thanks for the reply George. I'm not really worried about anything in particular, just potential issues I don't know about. Maybe there aren't any. It "SEEMS" like deleting all the features then re-loading them should start the OID's back at 0, so this is mostly just me being OCD I guess.