You want to "draw the relations" programmatically, right? I don't know how to do this. I think the DDL (1) can set a relation between a PK and a FK, and this might draw the lines. But this will leave all the triggers at "ignore".

Perhaps you can play with the DBC as a table, but this should be done with great care, lest you damage your database. (Especially, do a backup first).

Also, perhaps what you really want to do is reflect the changes you did on your machine, at the client site. In this case, the easiest solution, since it encompasses many things, is to have an empty copy of the new structure, and do an APPEND FROM for each table. Copy parent tables before child tables; see ADBOBJECTS("RELATION"). Or, use an alternate RI-tool, like TaxRI, that allows you to temporarily disable RI.


(1) Data Definition Language. In this case, see ALTER TABLE... REFERENCES.

>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.