Hi Jim thanks for your interest

I am using transactions. But I'm pernickety and I like to know if the row is deleted first. Before I enter the transaction, I call my CanISaveOrRevert method, which checks if the row I'm committing is dirty in the buffer and if the underlying row is deleted. So I needed a separate IsRowDeleted() method, which revealed the problem I posted. It reads an alias so it cannot affect the recordpointer.

If I TABLEUPDATE() within a transaction without checking first for a delete in one of the tables, I have to rely on the update error to let me know what happened. Not only can this be awkward where several tables are committed together, but then I think I'd need GETFLDSTATE() to work out the details so I could let the user know. Yes, a whole transaction could be reversed at this stage. I find GETFLDSTATE(-1) sees only this VFP session, so I don't rely on it there. Instead, I want to let user restore the delete (and child deletes made thru the VFP cascading delete) first, so there are no delete conflicts for the Error method to catch.

DELETED() is scoped to the datasession, which here contains a buffered table.
GETFLDSTATE(-1) also doesn't work from the disk file but refers to VFP's copy
in this session's memory i.e. to all datasessions in this VFP session.
This looks like 'unintended behaviour' to me, but whether intended or not
GETFLDSTATE() is not very helpful for finding multi-user deletes, as prototyping with two sessions shows. This behaviour has been reported on the UT too.

So yes, my design may be a bit different.

Cheers

Dick