>>>>>I'm not 100% now sure the second method will work. Does the delete trigger fire when you mark record for deletion (I assume it does). If so and you have RI defined (with CASCADE delete), you may not use the second method either :(
>>>>
>>>>Yup, we're back to the drawing boards. There is RI with CASCADE delete; great bunches of child tables. I started it about five minutes ago and it's still chugging....
>>>
>>>Ok, do the normal delete then
>>>
>>>delete OC from OriginalClients OC inner join ToRemove TC on OC.ClientID = TC.ClientID
>>>
>>>assuming we have index on ClientID in both OriginalClients and ToRemove the performance should not be too bad even with all the delete triggers firing in the background.
>>
>>That syntax isn't supported in VFP7, however it should be about the same as
>>

>>DELETE FROM MyDataBase!OriginalClients ;
>>	WHERE NOT DELETED() ; && Rushmore!
>>	AND clientID IN (SELECT clientID FROM ToRemove)
>>

>>And I had not indexed ToRemove in that attempt, so that's the next thing to try.
>
>I don't think you need to check for NOT DELETED(). Even if it deletes the second time, who cares?

You don't, but that is supposed to trigger Rushmore optimization in DELETE SQL that doesn't use it otherwise. Unfortunately, the index on ToRemove made no difference: it shows a query progress bar to 12% and then appears to hang. I suspect it will complete if I let it go for long enough, but neither I nor my customer has that long to wait.