>>>I have two tables in a database that are linked with a persistent one-to-many relation.
>>>
>>>I have configured VFP referential integrity to restrict deletions from the parent table when matching records appear in the child table.
>>>
>>>I have a main-form that calls a sub-orm that includes code to delete records in that parent table. This code does an INDEXSEEK in the parent form to find the record to delete, and uses the VFP DELETE command to accomplish the delete.
>>>
>>>The first time the main form calls the sub-form, and the sub-form attempts to delete a record in the parent table, RI delete gets triggered, and the deletion does not occur, and control returns to the main form.
>>>
>>>If the main form then calls the sub-form again, and again tries to delete that same record in the parent table, RI delete does not get triggered, the record in the parent table gets deleted, and the related records in the child table are now orphaned.
>>>
>>>Thanks in advance for your help.
>>>
>>>Jim
>>
>>Did you try setting a breakpoint on tableupdate and also in the trigger's code?
>
>Hi Naomi,
>
>Sorry it has taken me so long to get back to you. I got pulled off on something else.
>
>I used your suggestion about putting a breakpoint in the __RI_DELETE_projvisits code, the code called when I want to delete a record in the parent table (ProjVisits). As I step through the code, I can see that it works fine the first time that I try to delete a record in the parent table. The SEEK command in the RI DELETE code finds a record in the child table, and prevents the deletion. If I make a 2nd attempt to delete a record in that parent table, a very odd thing happens. When the __RI_DELETE code opens the child table before performing the SEEK command it open a table of the same name in a different database of the same name in another folder as the database I am testing. I have not yet been able to figure out how this is happening. When the __RI_DELETE code opens the parent table I can see that it has the correct path. Can't see where it is changing the path.
>
>I'll report back again when I've made some progress on this.
>
>Jim

Followup...

I just renamed the folder containing the copy of the database that I am testing. Now, __RI_DELETE_projvisits correctly finds both the parent and child tables, sees the conflict and prevents the delete.

Any thoughts on why it looked elsewhere for the child table?

Thanks
Jim