Walter,

Thanks for the all the info - sounds like a lot of thought went into your tool!

>Hi Nadya and brian,
>
>>>I'm glad it's working for you. I have to admit, I'm surprised anyone's gone to the trouble of rewriting the RI code... I've always been happy with VFP's generated code. I'll have to take a look at Walter's class - what advantages did you find it has over the VFP code?
>>
>>I'm not sure, I found them. I didn't understand VFP auto-generated code and I din't understand Walter's code either (haven't studied neither of them seriously). However, Readme claims, that it's better and faster than VFP auto-generated code, so I just rely on that. May be Walter can say something about it.
>
>I was rather unpleased with the VFP RI builder for the following reasons.
>1. The VFP RI code is unreadable
>2. The VFP RI code is far from efficient (repetative code).
>3. The VFP RI is inefficient when doing mutations on more than one record because it opens and closes related tabled for each record.
>4. The VFP RI code is not flexible: You can't turn it off under particular circumstances.
>
>The TaxRiBuilder creates more compact code, is more readable (though you need to take a good look from what is happening, Nadya ;-)), is faster, and is more flexible.
>
>In the VFP RI builder a whole new massive function of code is written for each net table that is involved in relations. In the TaxRiBuilder this means a new CASE statement (one for insert, one for delete and one for update) and a single line for the relation itself, which is much more space conservative.
>
>If you got a database with a large number of relations involved in RI, try to generate the RI code from the VFP RI builder and compare it with the code created with the TaxRiBuilder. You'll find that the TaxRiBuilder creates far more compact code.
>
>With a little effort you can see that the code created with the TaxRiBuilder is far more readable than the VFP Ribuilder, though I must say that you'll easely overlook the scope of certain private variables declared in _HandleRi. Some mechanisms which are not a prove of best coding practises are done this way because of performance issues (e.g. RETURN in the middle of a function).
>
>The taxRiBuilder produces code to make it possible to leave related tables open (_RImode = 1 - fast), to optimize REPLACE ALL, APPEND FROM, DELETE FOR, etc.. commands that operate on more than one record. You've got to call _RiCloseTables to close those tables manually.
>
>Further, It only begins a transaction when it cascades updates or deletes, tuning performance for those DML operations that do not.
>
>If you set _RIMODE to 0 (none), you can turn of RI for the table and action described in _DisableRi. (See generared code, or readme.txt in the download). This gives you the opportunity to bypass the RI if neccesary or to improve performance then doing a massive amount of insert or updates while you're sure this won't affect RI.
>
>The good old update-restrict and delete-restrict that maintains RI in your program, forbids the renaming or deletion of your articles while they're ordered by a customer, can be bend into cascading with adding 16 or 32 to _RiMode. This is particular usefull when the database contains false information, but the RI forbids the deletion or update of it. An administrator can (with the help of a command window) turn switch from restrict to cascading and delete or update the false records.
>
>IF you have some comments on the working of the TaxRiBuilder or some enhancement request, feel free to contact me.
>
>Walter,