The two child tables both have other parent tables. That shouldn't enter into it unless I try to RECALL ALL in those child tables, since there is nothing to cascade from the child to the parent. There are no grand-child tables.

What, more specifically, is your suggestion regarding table buffering and transaction processing? I hate to seem dense, but my testing is time-consuming and I would like to have a better idea of what to test.

VFP's own generated RI code has always looked pretty low-fat to me. I certainly wouldn't know how to write anything better.

When I did this before, all the tables would have been smaller, but I don't know how much smaller. I wish I knew how long this was supposed to take. If the slowness of cascading 4000 deletes to two child tables is expected, then I should probably cut the persistent relations with ALTER TABLE ... DROP FOREIGN KEY and then put them back when I am done. It reminds me of people who need to add a million records in one batch, who drop indexes or something, to avoid a million REINDEXes.

>Hi, Bret-
>
>I really don't know the answer to your question. It could be that it would more efficient for you to write your own cascade delete in this--at least to experiment.
>
>The RI is general purpose...and, in my experience, the more general purpose something is, the more code it has that's not needed for a specific case. So, of course, the trade off must be weighed.
>
>Is it a straight delete in the child tables that you need? They aren't related with RI to any tables themselves? If that's the case then perhaps a combination of table buffering and transaction processing is all you need?
>
>>When I leave table1 related to just one of the children, the DELETE FROM table1 takes 15 or 20 minutes
>
>...snip