Hi JimN ---

I assumed (that bad word again) that he had one record now but that,who knows?, may get bigger. My n-tier remark was on a different set of rules :-)

I guess I also took the literal definition of buffered.



>
>Jose didn't really say he was buffering, he said he was sometimes getting the data from the buffer instead of from the physical record.
>
>I *assumed* (we all know what that can do) that he is in fact UNbuffered, and speaking of the good ol' buffering of old.
>
>Cheers,
>
>Jim N
>
>PS Don't you think n-tier would be a bit of overkill for a high-access 1 record situation?
>
>>Hi Jeff ---
>>
>>Without data buffering (but Jose said he was buffered, hence my response) I have also run into the problem. I think it has to do with Windows read/write caches and internal buffering. I have never been able to eliminate the problem but I did reduce it by disabling the write cache in Win95 one time.
>>
>>I don't thnk the problem can be eliminated. I suspect that some call in Windows reports that something is physically written when it's not...so the report is milli- or microseconds off.
>>
>>I do what you do and just re-open the durn thing. But that's not an option (at least a practical one) if it's a multi-user table and there is a lot of traffic. In those circumstances, I abandon DBFs altogether and go to physical n-tier with SQL Server or Oracle.
>>
>>
>>>OK John splain this one to me.
>>>The reason I responded the way I did was I ran into the same problem. NO BUFFERING. Direct table access. Table was on a server, select 0,use table,
>>>this was a table that held one field and one record, one field and record only , always going to be one field and one record. Its a datetime field of the last time a process was run. Rlock did not do it for me. The only way I could get the new value was to
>>>a. close the dbf and open again.
>>>b. add another record that was blank and toggle between the two.
>>>
>>>I assumed it was because of buffering on the network and VFP's loading into memory. I guess I could have tryed a flush but did not think about it at the time. What else could I done?
>>>
>>>Jeff
>>>
>>>>Hi Jim ---
>>>>
>>>>I don't think he wants to "GO" anywhere. If it's row buffered. What I'd like to know is if this table will stay one record.
>>>>
>>>>>
>>>>>If it has only 1 record then
>>>>>
>>>>>GO 1
>>>>>
>>>>>should work just as well too.
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Jim N
>>>>>
>>>>>>I Got it
>>>>>>
>>>>>>I forgot to say the table has only one record
>>>>>>
>>>>>>I did this:
>>>>>>
>>>>>>Select Table
>>>>>>SKIP && Go EOF
>>>>>>SKIP -1 && Return to the record
>>>>>>
>>>>>>An it works great
>>>>>>
>>>>>>Thanks to everybody