Richard,
One of the "features" of private datasessions is that they are completely independent of other private datasessions, even on the same system. It seems to me (I may have misinterpreted) that you have uncommitted changes in PDS 1 and you are trying to do cascading deletes in PDS 2. First, wrap your delete code in a transaction as Jim Booth suggested. However, you may ALSO wish to cycle through all the open forms/data sessions and make sure that all pending data changes are updated or reverted before you start your cascade.

Finally, I know that you can cascade deletes downwards through children, grandchildren, etc. However, I didn't think you could delete UPWARDS from child to parent without specific code.

Barbara

>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