IFeatureWorkspaceManage2.GetObjectClassNameByID(int oid) equivalent in Pro SDK?

Question

We use IObjectClass.ObjectClassID and IObject.OID to identify an object in a geodatabase. We track that information for later use, e.g. open the object class. Since Table.GetID() is already implemented we could store that ID and later use "Geodatabase.GetDatasetNameByID()" to call Geodatabase.OpenDataset(). Or Geodatabase.OpenDataset(int id) would be convenient as well. Thank you.

RichRuh · Answer

As Wolfgang Kaiser‌ states above, you need to use a table name instead of an ID. Other than that your list above looks correct.

--Rich

marketsquarehero · Answer

In the ArcObjects code we stored the ObjectClassID and OBJECTID for the edit workspace. So we know what row our object is representing. We store these objects in the MXD/layer. And as I mentioned before, integers are easier to handle than strings. That's why I would love to have a method GetObjectClassNameByID() to use the table name later to open the table.

Typically the 'related table ID' field contains the same value for all our 'row' objects. But in some special cases the field might have a different value.

Since with ArcGIS Pro there are many potential edit workspace at once: how do store the identity of a row over many ArcGIS Pro sessions? Our solution right know is to use instance, version, user (from Connector type) or path (if it's a FGDB), table id and oid.

My latest question on geonet is somehow related:

https://community.esri.com/message/930889-unstable-rowhandle

sorry for my long inactivity..

Wolf · Answer

Sorry Daniel, this functionality is not implemented in the Pro API.  If i understand your data model correctly you store two object ids: one ID contains the object id of the related table and one ID contains the object id pointing to the related row in the related table.  So does the 'related table ID' field contain the same value (or referenced related table name) for all rows, or do some rows refer to a different related table name?  I can think of a few alternatives to implement this, but it would help to know some of these details on your data model.  Worst case you can add your own stand-alone table that contains an 'object id' and the corresponding table name.