Jim

> If you use a transaction and you have deleted a record in the parent, a tableupdate will succeed if noone else has altered the record and fail if anyone else has altered the record. If the tableupdate fails you ROLLBACK and Tabelrevert(), if it succeeds you let the RI triggers do the cascading delete, if that fails the tableupdate fails. If the tableupdate fails you ROLLBACK. Once you have succeeded on the tableupdate of the parent, no one else can get a transaction started until you either rollback or end transaction.

I do deletes exactly this way Jim. To prototype this I do them from a separate VFP session which I will call Session 2. But before I do this, the user in the first VFP session (Session 1 if you like) has started editing her buffer. Session 2 does a delete. The delete works exactly as you describe and it 'looks' fine. But when Session 1 later chooses a Save button and detects the delete, which as I say I check for _before_ starting to save her edits within a transaction, my code tries to RECALL it. Still outside any transaction. And though the RECALL appears to work, and DELETED() is .F. again, the row is not fully restored. DELETED() has been turned from .T. to .F.. _Next_ I begin my transaction, issue TABLEUPDATE() for this table and get an update conflict due to a deleted row in this table. While DELETED() is demonstrably .F..

Any tableupdate() also fixes the problem - the row can be RECALLed sucessfully now. Moving the recordpointer , calling UNLOCK etc. will fix it. So its easy to fix. By the way there are no locks involved in my code..

I think from testing this only happens when there are three layers of tables grandparent, parent, children - and it only happens if Session 2 deletes the parent (and thus cascade-deletes its children). Child deletes alone do not cause the problem. The children can be fully RECALLed by Session 1 when the deletion is diiscovered but as I say the parent is not properly RECALLed. The grandparent seems to need to be there but is not participating in these activities at all. I had no problems until I added a grandparent.

> You don't need to worry about what other user's have done until a tableupdate fails and you want to attempt to recover from the failure.

Mine is not the only way to code this maybe I'm being picky but I want to know if a delete conflict is going to arise before my tableupdate fails, so I check, and this is what I found. I had a bunch of other reasons for checking for deletes so I have a custom method reading an alias in the same datasession which makes it easy to check. If I don't check, there's a fairly messy situation to sort out when there are several tables' edits involved and cascading deletes are supported. I like my design better than putting the tableupdate/save inside a transaction and just trapping errors. (But I do trap those guys too). Any tableupdate 'fixes' the row so I would suggest the way to put it is that failed transactions may fully cloak this situation from the programmer.

> Getfldstate() is supposed to tell you about the current buffer's condition, not the disk file.

The Helpfile says 'Returns a numeric value indicating if a field in a table or cursor has been edited or had a record appended, or if the deleted status of the current record has been changed.'

OK there are different ways to read that but I'd sure like to know about the disk file! Do you or other users feel we _must_ wait for update errors before we consider delete conflicts?

Now, I haven't tested if more than one such row can exist - but if there are row(s) with 'bad delete' status in a table isn't that interesting? Anyone else seen these?

Cheers

Dick