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