Hi Hilmar,

Forgive me for being so tardy in my response and my thanks. You are absolutely correct and the application of your suggestion is exactly what I needed.

Thanks,

Ken


>Quite logically, the condition closep_ID = 0 checks for the new (modified) value of closep_ID being = 0. If you want to check the value of closep_ID before the user changed it, check for oldval("closep_ID") = 0.
>
>>Hi, I think I need a better understanding of the use of Triggers.
>>
>>Here is the situation. I have a table of financial transactions (FINXN). When I want to close a period and "cast it in stone" I flag the FINXN records that I do not want the user to be able to change/delete. The flag is accomplished by entering a value other than 0 into an integer field in FINXN ala Finxn.closep_ID = 8.
>>
>>In the DBC I have two triggers on the FINXN table: Both the update and delete triggers are "closep_ID = 0"
>>
>>So far so good... This yields the behavior I was expecting (almost). If the closep_ID in a Finxn record is NOT 0, any attempt to delete that record or to edit any fields on that record results in a "TRIGGER FAILED" message. That is GREAT! EXCEPT that I am able to modify the closep_ID field and change it from 8 to 0 without failing the trigger. Once I have done that, of course I can then modify all of the other fields.
>>
>>I think that is BAD behavior but it gets more interesting... If I change the closep_ID value from 8 to 0, now I cannot change it back to 8!.
>>
>>What am I missing ?? Perhaps VFP looks only at the new value of closep_ID and, since it is 0, changes are allowed??
>>
>>Thanks,
>>
>>Ken