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<T>(). Or Geodatabase.OpenDataset<T>(int id) would be convenient as well. Thank you.
Hi Daniel,
Can you elaborate why you are using the ObjectClassID versus just the table's name? I think one issue with using ObjectClassID (as well as Object Id) as identifiers is that they will change when you copy your tables or featureclasses to another geodatabase which in turn would render your identifiers obsolete. Rather than using these Ids i have always designed my systems which needed to track relationships (on an application level) by using the table name and a GUID type column.
Hi Wolfgang,
Thanks for your reply. My request is not super critical. But it would be handy I thought it’s low hanging fruit.
Different ObjectClassID (OBJECTIDs) in different workspaces: That’s a good point and you’re right. But when we store the ObjectClassID (and some state) in our lightweight objects we always refer to a specific workspace. So, this is not an issue.
IDs are just handy. We don’t have to fiddle with strings (qualified names, case sensitivity, table name lengths, etc.).
GUID type column: Our solution wouldn’t work if the column is missing. And we don’t want system/application information in our data model.
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.
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..
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