Hi Thomas,

I'm with you on that. Only that I simply try to fix what I see what is gone on the DBC - without looking to deep into what a (foreign) wizard or frame work is doing. I simply assume that a database created with VisualExtend that has information in RIINFO (IOW written by Extend) has this for a reason.

The guy likes to have his database fixed as automatic as possible.
I can remove the INDEX/RELATION from the DBC table (PRIMARY will be different fun) deleting the records, kill the CDX. Then I rebuild the stuff from scratch. This leaves problems with primary/candidates that are not longer unique - I know the values that are wrong, but this need to be solved - and the RIINFO for the FOREIGN KEY recreated.
I need a template, sure, but this a different problem.

Lutz


>Hi Lutz,
>
>I was ONLY speaking to RI-Trigger code - the Cascade, Restict & Ingnore stuff.
>First vfp implementations were buggy and ugly.
>Replaced all that with the Booth/Sawyer code as soon as available
>(got early access via Rainer) and have ot looked back since.
>
>Have not checked how xCase implements it, as I was not responsible when larger project used it
>but I never went back to setting the dbc RI manually.
>
>On VisualExtend: most vfp frameworks were ported form Foxpro Dos/Win implementations.
>Yes, it often shows in style of approach and programming - but Extend is still in the top 3 IMO.
>VisaulExpress, MaxFrame and VisualExtend duke for first 3 places,
>Promatrix gets in the fight if you use xCase and Hanks integration into Ptomatrix.
>
>With VisualExtend you probably have the broadest spectrum,
>but base working mind set is very old Foxpro with generators and wizards.
>
>OTOH it probably is the easiest fwk to replace certain aspects only
>From start on it had lot of template/hook patterns (when eventbinding was unheard of) -
>but overwriting at higher level meant to always rework on fwk update, which was a PITA.
>
>Faced with this and given the task to develop half a dozen large apps with it
>I ridiculed this approach only received "impossible to change 2.x design" answers ;-)
>I created some vcx mangling code to injected the corresponding user lib for every fwk lib
>sent this to Rainer with some msg to reward me for the "impossible" demand
>and refused to get involved in the already troubled dev task if this was not part of next release.
>
>Yes, working with it reminds of 80ies stuff, but the option to switch without recurring pain
>to self developed parts / routines and solutions replacing Extend stuff is best of all fwks.
>
>Every reason to switch RI code if DBC already broken.... And yes, relations are needed for most of the builders to work as designed, but IIRC that does NOT imply you have to use vfp RI.
>Probably MS fixed "buggy" on vfp 7 to 9, but left "ugly"
>
>regards
>thomas
>
>>I looked into that in the 90's, found that I need multiple (named) DBC's per program and never touched the whole MODI DATA again. I have a own meta system that fit's better to my needs all the time. I use own code that deals with this on business level. I have a kind of dynamic relationships, where two fields define the target and target table, this is all to complex for those builders. So I stuck with my RI - SQL solution 25 years old. :)
>>
>>The problem is with a friend who uses Visual Extend. He's not very deep into this, and the framework uses this builder stuff, and he has asked for help. So I was able to figure out what was gone and what to recreate, but died on the DBC.RIINFO or ADBOBJECTS(laArray,'Relation') 5th column.
>>As Al suggested one can circumvent this by carefully copying the DBC. So just creating all what one can create and then copy an old version of the DBC over it, looks like all fits.
>>
>>I end up fixing the CDX and VALIDATE DATABASE until he could open the crap and run it's framework's repair/update against it, and all was fine.
>>
>>Lutz