>>>Nadya, without known what do FieldChanged() is impossible simplify the logic;
>>>I can simplify the syntax, but the logic still the same:
>>>

>>>STORE GETFLDSTATE(-1)	TO row_State
>>>FOR iField=RAT('2',m.row_State)-1 TO 1 STEP -1
>>>   IF FieldChanged(FIELD(m.lnPos)) ;
>>>     AND !INLIST(UPPER(FIELD(m.lnPos)), UPPER("cLast_Updated_User"), ; && remove upper, VFP is not C !
>>>				UPPER("tLast_Updated_Date"))
>>>       REPLACE cLast_Updated_User WITH ;
>>>         IIF(VARTYPE(m.gcUserID) == "C", m.gcUseriID, getuserid()), ;
>>>              tLast_Updated_Date WITH DATETIME()
>>>       EXIT
>>>   ENDIF
>>>   STORE RAT('2',LEFT(m.row_State,m.iField))	TO iField
>>>NEXT
>>>

>>
>>Yes, that's basically the same. I try to avoid EXIT command, if possible. I think, my version is slightly more readable...
>
>No problem, you are able to choice, but remember:
>- readable : subjective is it
>- efficient : objective is it
>
>>Ok, I guess there is no simple way to get all changed fields in one command [I was thinking about some clever chrtran implementation here]
>>
>
>This is possible only with a new native VFP :
>

>=AFLDCHANGE(aArray,[[WORKAREA|ALIAS],RECNO()])
>* return a 2 columns aArray: fieldname,changeFlag
>* changeFlag bit0 set if not === oldval
>*            bit1 set if not === curval
>* === equal with null
>

>
>>I'll try to explain the problem I'm having.
>>
>>In my table I have a table rule called UpdateUserAndTime and a trigger called _ri_handler("UPDATE"). First fires the table rule. Here I check for fields which were modified and if I find that it's a true modification (e.g. not the same value put in the field) I replace LastUpdateUser and time fields and don't check for the rest of the fields. Then the trigger code fires. At the top it would be nice to check, if either of PK or FK fields are changed (since these are the fields participating in relations). If none of these fields changed, I don't need to execute the rest of the trigger's code. So, what do you think? How can I save myself from executing code twice?
>
>I understand.
>
>A 1 second idea:
>

>* add a parameter to the trigger
>- _ri_handler("UPDATE","UpdateUserAndTime")
>within  _ri_handler:
>IF PCOUNT()=2 and !EVAL(m.cParam2) && call the routine, and put within it the PK FK test
>     RETURN
>ENDIF
>* change the name to a more generic name
>UpdateCheck
>

Interesting idea. E.g. if I have an update trigger, remove table rule and put it inside the trigger (may be using slightly different procedure). I like it, but may need to discuss first among colleagues.