Well, actually it is part of the Mere Mortals framework, but the idea is simple:

When a record is added in a view, there is code that goes out and determines what the default value is for the PK. It then runs this code and updates the value in the view. After this is done, SETFLDSTATE() is used to set the PK back so that VFP doesn't think it has been modified. This is so that a cancel operation can be done on this record if nothing has really been done. This is NOT where the problem occurs.

When we are ready to commit the record (save), there is code that checks to see if this is a new record, and it will then use SETFLDSTATE() on the PK to set it to a 4 (new and modified I think).

As soon as it does this, the view becomes corrupted. Now, I assure you, this is very common code within the framework, and I can't see anything wrong with it. It seems to be a problem with VFP, but I'm not sure, and I was wondering if anyone has had similar results with SETFLDSTATE().

A little background on my view. It is table buffered. I believe I have 2 indexes built on it. It represents child records within my transaction.


>Doug,
>
>I have had trouble with this command - basically it allows me to switch between 1 and 2 or between 3 and 4 but that's all. It's also been flaky enough that I stopped using it.
>
>What are you trying to do? Perhaps there's another way around it?
>
>>Can anyone give me any ideas why my table buffered view is getting corrupted when I issue a SETFIELDSTATE("myid", 4)?