I seem to have a problem in VFP 5.0 with incompletely committed cascading deletes.
I am debugging a datahandler class which handles multi-tables/multi-user. (BTW, using optimistic row buffering). I try to detect deleted rows and handle the issue _before_ allowing an update conflict, as I am not entirely happy with GETFLDSTATE()
distinguishing the kinds of update errors.
When the table is a parent and a child, both the row and its own children may be deleted by the VFP engine when the user in another session deletes the row. That's fine.
However if there are pending edits the PARENT table row is not seen by a second VFP session as truly DELETED() until a TABLEUPDATE runs from the second session. Even if the row is RECALLed and DELETED() returns .F., if there are pending edits in the second session, a delete conflict error will still arise. It appears that the deletion is not committed for the PARENT although the children are committed, and the RECALL is then incomplete as the VFP engine has become confused. This causes failed RECALLs, although DELETED() is successfully restored to .F.

The problem however is not RECALL but seems to be the incomplete DELETE of the parent row in the first session.

In my testing this was OK until I had three 'layers' of tables (grandparent, parent, two children). Because as mentioned it is only when the table involved is both a parent and a child (of the grandparent) that problems seem to happen.
My workaround is to restore the parent row, saving any edits, issue TABLEUPDATE(0,.T.,table) then RECALL that row and recall recently-seen child rows, and REPLACE the parent's edits then proceed to the 'rest of the save'.

May I ask, has anyone else seen this?

Cheers

Dick