nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Maintain OBJECTID values when importing a featureclass

MarkSmith

Hello,

I've done a bit of searching on the forums and this doesn't look hopeful, but here goes:

I'm migrating databases and want to move an SDE featureclass from the old database to the new V10 database. However I want to copy across the OBJECTID values too. The problem is the OBJECTID values don't get read when I import the layer to my awaiting new featureclass.
Is there a solution to this please?

I've tried different methods of exporting and importing but the result is always the same �?? I'm unable to maintain the OBJECTID values in my new database - all the other attributes come across fine.

Thank you,

Mark.

Encontre mais publicações marcadas com

Accepted answers

All comments

Bud

EMCAdministrator

My issue is that I want to preserve both the object ID and GlobalID values. Export features can preserve Global ID values but doesn't preserve Object ID values. Copy/paste features preserve Object ID values, but not Global ID values. Can't edit an ID field so can't do any spatial join workarounds either.

GregBury

Craig and Asrujit, thanks! Your replies made things clear here.

AsrujitSengupta

Yes, the manual Copy/Paste of the data and the Import/Export as XML workspace documents preserves the ObjectIDs of the data.

cgillgrass

Greg, to clarify, the Copy/Paste functionality that I referred to in the post is the Copy/Paste functionality available through ArcCatalog/Catalog window; not using the copy/paste commands in the Editor.

GregBury

Can someone confirm Craig's suggestion here; that OIDs are preserved using Copy/Paste?

I'm trying to rollup changes from non-versioned GDBs, seeking to preserve the OIDs; the source and target feature classes would have the same name (i.e., structure_existing_area) in two GDBs (i.e., Test and Default)

- using "manual" editing (delete features in Default; select all in Test; copy; paste into Default) did not preserve the OIDs; the pasted features were all "renumbered"

- the "Copy Features" tool (with geoprocessing option "Overwrite = on") reported success, but the paste failed; the Default feature class had zero features after the tool finished/reported success

Thanks,

Greg

cgillgrass

Mark,

Instead of using the import/export tools, try using the Copy/Paste functionality, this will preserve Object IDs from the source to the target geodatabase.

VinceAngelo

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

MarkSmith

Thank you for your reply.

I don't know the intricacies of SDE, but it's a shame this can't be achieved �?? from my point of view if a dataset can exist in one SDE database with a certain sequence of OBJECTID values, then why shouldn't it exist in another with the same values? I'm prepared to accept it can't be done, but it's a shame.

Thanks again,

Mark.

VinceAngelo

There is no method using ArcGIS tools to populate SDE-set rowid columns with previously
existing values. In a number of respects this is the last thing you want anyway, since it also
means there is no hope for doing spatial defragmentation on database copy.

- V

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.