topic Re: OBJECTID Inconsistent when features from one GeoDatabase to another in Data Management Questions

OBJECTID Inconsistent when features from one GeoDatabase to another

huangJary — Tue, 08 Jun 2010 04:46:23 GMT

I Create an InMemoryWorkspace, then get featues from one FeatureClass in a SDE Geodatabase, add into a FeatureClass by InsertFeature function, and the result is that the objectID of feature is inconsistent compared with datas in SDE Geodatabase.

How to keep consistent in ObjectID?

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

VinceAngelo — Tue, 08 Jun 2010 11:40:35 GMT

The only way the objectids could be consistent is if you a) selected all features, b) inserted
them in objectid order, and c) the source dataset started at 1 and did not have any gaps.

If you want to preserve the old ids, you'll need to insert them as an additional column (e.g.,
"prev_oid integer not null"), since there are no guarantees about SDE-set objectid allocation
(except that they will be unique non-zero positive values).

- V

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

CraigGillgrass — Tue, 08 Jun 2010 11:42:43 GMT

ObjectIDs are managed and controlled by the Geodatabase, they are also unique within a given feature class/table within a Geodatabase. You cannot control the values assigned as ObjectIDs within a feature class/table. While the Insert cursors do not maintain ObjectIDs between feature classes/tables, since you are inserting new records into the target, Copy/Paste does maintain ObjectIDs. Why do you need to keep the ObjectIDs consistent between your source and target Geodatabases?

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

huangJary — Tue, 08 Jun 2010 13:22:46 GMT

ObjectIDs are managed and controlled by the Geodatabase, they are also unique within a given feature class/table within a Geodatabase. You cannot control the values assigned as ObjectIDs within a feature class/table. While the Insert cursors do not maintain ObjectIDs between feature classes/tables, since you are inserting new records into the target, Copy/Paste does maintain ObjectIDs. Why do you need to keep the ObjectIDs consistent between your source and target Geodatabases?

For example, I get part of datas from a SDE GeoDataBase, and add into an InMemoryWorkspaceFactory, I will Modify�?�Add or Delete Data, then finally I need add datas which are in memory into a SDE GeoDataBase. The ObjectID need to keep consistent. if ObjectIDs are inconsistent, I only create a Table in managing ObjectIDS.

Are there better methods in solving this proplem�?

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

huangJary — Tue, 08 Jun 2010 13:26:59 GMT

The only way the objectids could be consistent is if you a) selected all features, b) inserted
them in objectid order, and c) the source dataset started at 1 and did not have any gaps.

If you want to preserve the old ids, you'll need to insert them as an additional column (e.g.,
"prev_oid integer not null"), since there are no guarantees about SDE-set objectid allocation
(except that they will be unique non-zero positive values).

- V

Thank you for your answer, are there better methods in solving this proplem?

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

VinceAngelo — Tue, 08 Jun 2010 13:49:55 GMT

You can't control the objectids in either location, and can only keep track of old IDs
and edits through a great deal of effort. It's generally easier to use ArcGIS as it has
been designed, so I think you should look into the Disconnected Editing model.

A search on "Disconnected Editing" should pull up a wealth of information.

- V

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

JamesMacKay — Tue, 08 Jun 2010 22:32:48 GMT

It's also important to remember that an in-memory workspace is not a true geodatabase. A lot of things that work in geodatabases will not work with in-memory workspaces (copy/paste, for example). If you want to use a temporary geodatabase, your best bet is to use a Scratch File Geodatabase. This link describes how to use them:

http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/creating_geodatabases/0001000004t8000000/#CreateScratch

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

szcszc — Wed, 09 Jun 2010 08:23:46 GMT

You can't control the objectids in either location, and can only keep track of old IDs
and edits through a great deal of effort. It's generally easier to use ArcGIS as it has
been designed, so I think you should look into the Disconnected Editing model.

A search on "Disconnected Editing" should pull up a wealth of information.

- V

In ArcEngine "Disconnected Editing", the ICheckIn�?�ICheckOut can keep OBJECTIDs consitent�?but this process is encapsulated in ArcEngine. Such as host said, if I need get featureclasses or tables from a SDE Geodatabase into a InMemoryWorkspaceFactory, how to keep OBJECTID consistent?

Re: OBJECTID Inconsistent when features from one GeoDatabase to another

VinceAngelo — Wed, 09 Jun 2010 11:48:10 GMT

You cannot control the allocation of SDE-set registered rowid column values in geodatabases
and "in-memory workspaces" aren't, as James pointed out, full geodatabase implementations.

The task of keeping track of pieces of a database, editing them, and merging the result back
into the original table is quite challenging, which is why the Disconnected Editing solution was
developed. But you can't pick and choose pieces of that solution (the restrictions it imposes
were necessary to make the solution work).

If Disconnected Editing doesn't meet your requirements, you'll have to decide if the days,
weeks, or even months of effort to make your own in-memory solution are worth your time,
but your design will have to actively track previous objectid values in an additional column,
and be prepared to update, delete, and insert appropriately when the transition back to
persistent geodatabase occurs.

Good luck.

- V