Select to view content in your preferred language

Export FC while maintaining ObjectID values

814
4
Jump to solution
11-14-2023 12:00 PM
Bud
by
Honored Contributor

ArcGIS Pro 2.6.8; Oracle 18c 10.7.1 EGDB:

Short Version:

I want to export a FC from prod to dev. I want to maintain the ObjectIDs from prod when exporting.

Long Version:

I have a prod FC that has ~2,100 features where the shapes are blank:

where
sde.st_isempty(shape) = 1 or sde.st_isempty(shape) is null

Select features that have blank shapes 

I want to determine why the shapes are blank. I want to compare the shapes to an older copy of the FC; our dev database is an option:
Dev was created 7-8 years ago; it was an exact copy of prod at that time. So I want to compare the prod FC to the dev FC, to see if the corresponding shapes in dev are blank. If the shapes aren't blank in dev, then that tells me that something went wrong in prod at some point; maybe a user accidentally did a field calculation: SHAPE=None, etc.

I want to perform the comparison using a query in SQL Developer, using a connection to dev. However, dev can't see prod data (they're entirely different databases), and I wouldn't ask I.T. to set up a DBLINK from dev to prod just for this one thing. So querying both dev and prod in the same SQL Developer connection isn't an option. I want to export a copy from prod to dev instead.

Unfortunately, there isn't a user-defined unique ID field in the FC, which makes comparing the two FCs difficult. So I want to compare ObjectIDs instead (the ObjectID values in dev are the same as prod; the ObjectIDs weren't reset when prod was duplicated as dev).

Problem:
I want to export the prod FC to dev, but I want the ObjectIDs to be maintained so that I can make the comparison. How can I do that?

I don't want to create an OID_STATIC_COPY field in prod (using a field calculation). The FC is locked and that would be undesirable anyway.

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
DavidPike
MVP Frequent Contributor

Copy and paste in the catalog window of Pro will do this, or Copy_management (not copy_features) https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/copy.htm

View solution in original post

4 Replies
Bud
by
Honored Contributor

I tried creating a query layer that has a calculated column to hold the ObjectIDs:

select
    objectid,
    project,
    objectid as oid_static,
    shape
from
    infrastr.inf_record_sp

But the query layer is too buggy in ArcGIS Pro.

  • If I use a WHERE clause to select only the blank shapes, then only a handful of rows are returned (incorrect).
  • And without the WHERE clause, the query layer returns fewer rows than the original FC (about 2,000 rows less). Best guess is it's automatically removing rows that have blank shapes, which defeats the purpose of what I'm trying to do.
  • Idea: Query Layers — Include features with null shape in attribute table

I had planned to export the query layer as an FC from prod to dev (with the ObjectIDs maintained in the calculated column). But I don't think that will work due to these bugs in the query layer.

0 Kudos
DavidPike
MVP Frequent Contributor

Copy and paste in the catalog window of Pro will do this, or Copy_management (not copy_features) https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/copy.htm

Bud
by
Honored Contributor

Regarding, "Copy and paste in the catalog window of Pro will do this":

Good call. I didn't think this was the case originally. I navigated to the last row in the attribute table of the source FC and the pasted FC. The ObjectID of the last row was different between the two FCs. But I see now that the rows are in a different order in the pasted FC. So that explains why the last row's ObjectID didn't match.

However, I just needed to sort both FCs (ascending) by ObjectID. Then, I could clearly see that the ObjectIDs matched.

Idea: Copy/paste FC in Catalog — Maintain row order

VinceAngelo
Esri Esteemed Contributor

An export (exp or expdp) of the table would of course capture all column values, as would an import, though it's been too many decades for me suggest how to alter the intermediate SQL file to prevent difficulties while re-registering the resulting table.

- V

0 Kudos