Erik,

I am curious too, and this is definitely the kind of information which NEEDS to be in the VFP docs and not just in some KB article somewhere!

One can rationalize it either way, so we need to be told the INTENDED way so that we know what we are working with. Making up our own "rules" based on what we observe just doesn't cut it, not to mention that it *could* be a bug (which we can never know if we are not told the intended design in the first place).

Hopefully VFP 6 will improve the docs.

Cheers,
Jim N

>>I have noticed something weird, and to be honest quite scary:
>>
>>The following code yielded different results:
>>
>>
>>1.
>>select Airinfo
>>set order to 1
>>if seek(this.cMawb)
>> scatter memo name this.Airinfo
>>else
>> error ...
>>endif
>>
>>2.
>>select *;
>> from airinfo;
>> where mawb= this:cMawb;
>> into cursor crsM1
>>if _tally- 1
>> select crsM1
>> scatter memo name this.Airinfo
>>else
>> error ...
>>endif
>>
>>
>>
>>The first version gave correct results.
>>The second version stores the correct record, but a version that dates of before an update that occurs during the same session (meaning no open/close took place between the update and the select).
>>The only way I could have the sql select statement yield correct results is when I unlocked the record before the select statement, so that the table get flushed.
>>The tables are plain dos compatible DBFs, no DBC. The update is executed with an sql update.
>>In between, another station "sees" the updated version.
>>
>>So I conclude that an sql select does not see unflushed buffers, but seek and all the other stations do ...
>>
>>Is this weird, or is this weird ...
>>
>>Marc
>
>
>Not so much weird as annoying.
>This caught me a few weeks ago also. I had to completely rewrite the way I was doing things because I needed the data from the dirty buffer, and I didn't want to commit it yet. I am curious to hear if the behavior is by design and why?