>>>>I have a customer table which has 3 associated child tables; customer.custid is the primary key in customer. Custid is the the foreign key in the child tables. I have "Update" and "Delete" rules established in the RI builder.
>>>>
>>>>When I have the customer table open and I do a block replace such as REPLACE ALL CUSTOMER.MAILOUT WITH .F. the update trigger runs for every record - which takes a long time. I assumed the trigger would only run if the key field was being changed.
>>>>
>>>>Is there some way I can prevent the trigger from running as this particular update has no requirement to check the RI of child tables? Or maybe I have a fundamental misunderstanding of how this works.
>>>>
>>>>Barry Sutton
>>>
>>>Barry,
>>>
>>>The trigger has to run. It will exit when it finds that the key field has not changed
>>
>>Gregory,
>>OK, but despite this, it is taking in excess of 3 minutes to do the REPLACE ALL in 12,000 records over a network as the RI checks each of the child table key fields - running all the associated RI code to achieve this.
>>I have now introduced a stored procedure which checks the value of a global flag glDisableRIUpdates (.t. or .f.) and if set to .f. it allows the _ri_update routine to run; if set to .t. it returns without running the _ri_update code. This has speeded up the operation to a few seconds.
>>The only downside I can identify is that if I change the RI code via the inbuilt RI builder wizard, the _ri_update procedure name is reintroduced into the database container against the customer table and I have to amend this to point to my own (intermediate) stored procedure.
>>It seems odd to me that the _ri_update is called on fields other than the key fields as the latter are the only ones that would seem to be critical to the RI aspect.
>>
>>Barry.
>
>
>Long time ago that i had a look at the 'standard' fox code of the RI ( written mine )
>Just looked at some code that is generated - it tests whether the value has changed - if yes, it open the child table, etc
>
>But 3 minutes compared to a few seconds - I cannot believe it - sure you did not have the debugger open when yoiu had 3 minutes ?

Gregory
No to the debugger... it was the exe running on the network which was taking so long to process the replacements. My local dev project was much quicker, but even then half a minute compared to a couple of seconds with my kludge of a workaround to avoid the RI code running. I think I will consider it sorted for now.
Barry