>...errrr....doesn't.
>
>I haven't tried to use this function since VFP 3.0 but a recent project forced me to rethink it. I have a opt. table buffered view with 1 or more rows showing numeric data in a grid. I have to provide a mechanism to run a conversion on the number and I don't want to affect the current GETFLDSTATE status or revert the table because some changes may have already been done. So I came up with the idea of scanning through the records, storing the current field state values via GETFLDSTATE to an array, making the change using a SQL-UPDATE to the view, and then restoring the old field states with a loop through the array and SETFLDSTATE.
>
>Sound simple?
>
>Ain't working. The changed fields are showing "2" after the SETFLDSTATE. I can do this all day from the Command Window and no problems occur.
>
>What the heck am I overlooking?

I remember looking into something similar to this with SETFLDSTATE() a few months back. I think the upshot was that SETFLDSTATE() doesn't really work (at least up to 5.0, I don't know if it's been fixed in 6.0).

It seems that *all* SETFLDSTATE() does is fool GETFLDSTATE(). It doesn't affect whatever attributes VFP uses to determine if a field has been "changed", for example when updating a view.