>As I was working on an app the other day I was considering the roll that triggers should play. There are usually two schools of thought regarding triggers. The first school believes that triggers should be a last line of defense in case programmatic code misses something. In this school of thought, when inserting a new record into a table, the programmers code should check for duplicate or missing key values and the VFP insert trigger would only be used if there were some hole that the programmer overlooked. The second school of thought believes that the VFP trigger should do all the work with no additional programming to check for or trap missing key fields. So, when inserting a new record, the programmer does nothiing and waits for VFP to catch any missing or duplicate key values.
>
>I like the idea of VFP doing everything automatically, but am hesitant to use vfp triggers exclusively. What is everyones thoughts on this?

Michael,

I tried triggers, but I find it very hasardeous and so I do not use them at all. I think the .DBC feature is not robust enough to entrust with code when one considers the fact that when an application is in production, the .DBC is open, which means if I am not mistaken, that one can either change the code or let the users work ... Of course these consideration are only valid in multi user environment, but still...

My 2 BEF,

Marc