>IOW, I want to allow blank values in the field, but enforce RI on the foreign key when the field is not blank.
>
>I used the RI builder to create a relationship between the parent and children tables. It created triggers exceeding 80 lines each (is this a performance problem?). The triggers it created will not let me leave column col1 blank in this example.
>
>I see a few options to overcome this situation:
>
>1) Add a record in the referenced (or lookup) table with an empty primary key. This is easy, it works, but records with empty keys are bad things.
>
>2) Modify the trigger the builder wrote to overlook blank values. Of course, the modification will be lost the next time I run RI builder (is this a true statement?)
>

Yes this is true.

>3) Write triggers manually.
>
>4) Don't use triggers. Enforce somewhere else (perhaps in a business object)
>

Both 3 and 4 are options I would recommend under different circumstances.

If you want to use triggers, do them manually. While the VFP RI generator is good to start with, the code it creates is *not good* (that's kind :-)). It's huge, klunky and (I heard) buggy. You can write better code. You know the environment you are working with and you can make better decisions of how to structure things than VFP by itself can.

Another reason to use triggers is they will always fire no matter how you access your data. If you use an ODBC interface to add/delete records then your trigger will fire. The same can't be said regarding business objects.

Option 4 is good if you know your data will not be accessed without the use of your application. This limits your interface possiblities but if you make your business objects generic enough and scalable they may be ablr to be used as COM components for other systems accessing your data.

Just my $0.02.