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