Fabio:

OK, my mistake.

Good catch!


Pertti


>
>Fabio:
>
>Hmmm... Why would you want to reset the flag with SetFldState() without also resetting the value it refers to?
>
>
>I do not say this, but I say just the contrary.
>
>
>In my case I reset the flag AND the value in the buffer, but I still get a change flag from GetNextModified(), but no flags from GetFldState() for the same record. I'm using VFP6 on this.
>
>Pertti
>
>
>This behaviour is on VFP6 and VFP7, but on VFP8 change.
>
>On VFP6/7 control of buffers,
>and fields state are delegate to the developer,
>this can to be a trouble, but it is simple to remember,
>- elements are : fields,buffer,states
>- simple functions for they's control, all functions do a single operation;
>- TABLEUPDATE() write buffered data into the dbf file,
>and if it is a RV updatable VFP send updates to the backend.
>
>On VFP6/7 you can skip buffered reverted fields with simple code,
>you must check GETFLDST() after SETFLD() or GETNEXT()
>and do a RECORDREVERT() if the records is unchanged.
>

>* after GETNEXT example
>rNext=GETNEXT(...)
>IF m.rNext#0
>	GO m.rNext
>	IF '2' $ GETFLDST(-1) OR '4' $ GETFLDST(-1)
>		* UPDATE
>	ELSE
>		TABLEREVERT()	&& RECORDREVERT
>	ENDIF
>ENDIF
>* after SETFLD()
> replace field with OLDVAL("FIELD")
> SETFLD("FIELD",1)
> IF NOT( '2' $ GETFLDST(-1) OR '4' $ GETFLDST(-1))
>	TABLEREVERT()	&& RECORDREVERT
> ENDIF
>

>
>On VFP8,
>GETNEXT() ignore records with buffered data and with recordstate reset ( all fieldstate resetted ),
>but SETFLD() do not a automatic FIELDREVERT() and RECORDREVERT if recordstate is reset,
>then revert of field value is delegate to the developer.
>
>But a Remote View, VFP8, when you do a TABLEUPDATE(.T.),
>it write all buffered data into the file,
>but use only the GETNEXT() list ( a memory C array ) for send data to the backend !
>
>This split the TABLEUPDATE() operation in two operations,
>and then the probability that a VFP application can fail is increased.
>
>If the program not revert the fields values ( you do this into your code ),
>you have that local data and remote data with different values,
>and you do not have a fast way for check this.
>
>Normally, after a tableupdate a REQUERY() or a REFRESH() is done, and this resolve the problem,
>but if a developer have lock backend data in exclusive mode,
>it do not have a reason for REQUERY() ( except if backend table use triggers that change the values).
>
>It is obvious that if the developer is remembered all,
>it controls all the possible cases,
>and writes a perfect program, whichever argument is useless.
>
>I continue to write this general concept into UT:
>or the engine ( VFP ) do a complete operation correctly,
>or it do none and the developer use simple VFP elements for do it;
>Engine ( VFP ) partial operations
>are always confusion source
>because they increase in combinatory mode the ways
>of operations of the engine that is used
>
>A solution exist, and it is very simple to implement:
>
>On VFP9 ( or VFP10 ) VFPT add two new nfldstates 11,13 values for the SETFLDSTATE
>( i prefer bits flag ( 0,1,2,3,4,6 ) , but original 1,2,3,4 choice destroy this possibility )
>for implement a automatic FIELDREVERT() and a RECORDREVERT().
>
>On conclusion,
>

>or VFP9/10 do all the operation with a new FIELDREVERT() or SETFLDSTATE(,11):
>- revert the fldstate flag ( current behaviour )
>- revert the field value   ( put OLDVAL() into the Buffer )
>- remove the record buffer if all fldstate flags are resetted to unchange
>
>or VFP9 work like VFP6/7, and the job it is left to the developer.
>

>
>Now, VFP8 behaviour is not backward compatible,
>and it is a greater problem because i have not found documentation for this,
>then it is a app or doc bug.
>
>Fabio