>Scary, but not weird, Marc.
>
>A SQL-Select always looks at the data on the network, NOT any buffered tables that are already open. I don't think it's possible to get the buffered data without saving it by using SQL. As you found out the Scatter/gather WILL give you the correct information from updated files, as will 'Copy to' and other commands using the open tables.
>
>Barbara

Are you aware that this happened on plain dbfs? No ;DBC, no sofisticated buffering is going on! Just that the data were not flushed in the good old dos sense. And btw, from other stations, I did get the correct information back for sql select ...

I persist. Scary _and_ weird.

Marc


>
>>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