I should clarify -- If you can't change the objectid sequence, then you can't change feature order,
and that would mean you can't optimize your data. Instead, the copy uses the SDE-set IDs, which
allocate sequentially, without regard for previous order, leaving the opportunity for optimization.
It is often the case that copied rows *do* have the same rowid column value when being copied,
but because the tables are constructed using SDE-set IDs, it is not possible to guarantee it (and it
wouldn't be possible anyway if the previous table had been edited so that the SDE-set IDs were no
longer sequential).
The only way to preserve objectid values would be to use database and ArcSDE tools to change the
table to USER-set rowid, export the data, import it as USER-set, then alter the source and target
table registration to be SDE-set. The thing is, if you're going to do the work to make *this* happen,
then you should put forth the extra effort to do the query in spatial index order, which would optimize
created feature order, which should result in improved performance with every query. And if you're
going to do that, then you should also optimize your coordinate refererence to reduce storage and
improve query performance. And if you've made all theses changes, what difference would it make
if the objectids were assigned in creation order, since you really shouldn't be using SDE-set rowid
values for external application purposes anyway.
- V