>>>>Marc,
>>>>
>>>>There is also ( at least it is my perception in reading here and on MS NewsGroup ) the problem of too many reported instances where they simply do not fire.
>>>>I am still "learning" VFP but have concluded that Triggers should be left aside for the time being [several other 'features' too].
>>>>
>>>>Regards,
>>>>Jim N
>>>>
>>>>>
>>>>>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
>>>
>>>
>>>I totally agree. I leave them alone especially when VFP 3 had a bad time with them -- never could get back into it.
>>>
>>>The hardest thing, IMO, is to make rules that are 100% across the board. Remember a trigger handles all code & all circumstances. That is sometimes tough to do. When Michael said 'as a last line of defense' I tend to agree. Maybe they should be the catch-all since they need to be so general.
>>>
>>>Right now though I bypass it. But if anyone is using them I would be happy to know the results.
>>>
>>>Thanks
>>>Tom
>>
>>I use the add trigger for assigning unique values from my
>> unique value table. Works great.
>>I use the delete trigger for deleting related records in child tables.
>> Works great.
>>
>>I don't use the update trigger because as others have said,
>> by the time the data is being placed in a table, I believe the
>> data should be correct.
>
>
>Should I 'assume' you are working with VFP 5.x?
>

Yes I am.