Hi Hilmar

Thanks for responding. Actually the reason I wanted this is because I have fixed set of RI that I want to do at the first time the tables are created. I had a tough time dragging and dropping iid (PK) to ipid (FK) or iid to iitemid (FK) then right clicking that particular thread and calling VFP-RI builder.

I just want to mention:

DO genri WITH mAccounts, iID, tSaleBill, iPartyID, Cascade, Restrict, Ignore
DO genri WITH tSaleBill, iID, sSaleBillItems, iPID, Cascade, Cascade, Ignore

and my initial work is done. I dont mind running VFP-RI to do the actual dirty work.

Any ideas.

>
>To add procedures to the stored procedures, see APPEND PROCEDURES.
>
>To modify a trigger to a table, see CREATE TRIGGER.
>
>The actual trigger function for RI would have to search the key value, check in related tables, and return .T. or .F., depending on the type of trigger, and on whether the value is found.
>
>For example, for a delete trigger (in the parent table), if the value is found in child tables, the function should return .F. (DELETE is not allowed). Otherwise .T.
>
>For an insert or update trigger (in the child table), if the value is NOT found in the parent table, your function should reurn .F.
>
>
>If you want to redesign the RI completely, I have an idea that it might be interesting to use a single RI-function for all tables, and use a table-based approach. In other words, have your RI-function check a "relations" table, and search according to the parameters it finds there.
>
>Then, to redefine RI, you don't even need to recompile the stored procedures.
>
>
>On the other hand, I don't know whether such an effort is worthwhile; you can just as well use the built-in RI.
>
>Greetings,
>
>Hilmar.