how to return OID of row sitting in top of undo stack (Undo Database Row Change)

[JillFritz]

In an edit session, when the user clicks undo (which will Undo Database Row Change), I need to programmatically identify the row ID's that are about to be undone. I'm listening with _OnUndo, what interface will return the OID's of the pending undo rows?

I understand IDifferenceCursor is used when comparing different versions; but this is not what I'm doing. I'm not comparing differences. I'm using the returned OID's to programmatically make changes to an external standalone table (not targeted in the edit session) containing completely different data.

Thanks,
Jill Fritz, USFS Region 6

[AlexanderGray]

There may be multiple features in different feature classes and multiple rows in multiple tables edited within the same operation.  This way the undo stack does not point to a single objectid.  It points to a state in the database (sde or filegdb.)  The geodatabase keeps track of all the edits through states.  All the edits that belong to the same operation belong to the same state so when you undo you are potentially undoing multiple changes.  If you are dealing with a remote database (sde) you could figure out the inner workings of sde and try to do your non-arcobjects updates that way.  The risk of course is esri changing all the plumbing while keeping the programming interface intact, which they have done a few times already.  To do edits to outside tables like you describe you will likely have to build your own operation stack through custom code and keep them in sync.

[JillFritz]

Since I'm listening for Undo Database Row Change and Undo Database Row(s) Calculated only for the most recent undo, can I not use the sde gdb state to track the last edit/s and retrieve the OID(s) of those edits?

I want to allow the feature class undos to proceed normally. I'm interested in changing record(s) with the same OID's in an external table.  In an external table, I need to programatically "undo" the correponding record/s that was programattically created with the last user feature edit(s), right before the undo.

Or am I misunderstanding states. Are they not pointers?

Thanks,
Jill, USFS Region 6

[AlexanderGray]

Hi Jill,
In my experience using the OID as a foreign key in a database has only led to disaster.  The geodatabase manages the OID itself for geodatabase internals.  Imagine you have to transfer data to another database (partial or complete transfer)  all you the objectids are going to change when you reload the data and none of them will match the foreign key in the external tables.  You will be stuck doing database backup/restore type operations every time you need to move data around, even if you want a small portion of it.  Also if esri ever change the internal workings of the geodatabase, which I understand they have between 9.3.1 and 10, you run the risk of being unable to upgrade.

[JillFritz]

It's no problem for me to create a different foreign key field and not use the OID field as the foreign key.

Goal: During any edit session, I need to programatically "undo" the [external table] record/s that was programattically created in response to the user's last attribute edit(s), right before the user selected undo.

Method Question: Since I'm listening for Undo Database Row Change and Undo Database Row(s) Calculated only for the most recent undo, can I not use the sde gdb state to track the last edit/s and retrieve the foreign key of those edits?

Or am I misunderstanding states. Are they not pointers?

Thanks,
Jill, USFS Region 6

[AlexanderGray]

Hi Jill,
You could potentially use the state and the state lineage to know which rows were touched.  However the ArcObjects do not give you any clue as to which state was created.  If you have multiple versions being edited at the same time you would need to know which version and which editing session you are dealing with to figure out which states are relevant to you.  Multiple users editing on the same or different versions will be creating new states.  To be honest I am not all that familiar with the changes in the geodatabase tables for arcsde 10, I know the 9.x stuff better, maybe it is simpler now.  The thing is states and state_lineage and other geodatabase tables are mostly considered internal to the geodatabase.  Relying on detailed knowledge of the inner workings of the database to make your application work is not something I am comfortable with.  There is a risk that the application may not work in all circumstances (non-versionned editing or move to base versioning) and the application may break with changes to the internal mechanics of the geodatabase.