Buffered or un-buffered?

[IlyaRabyy]

Colleagues,

It's a theoretical question: when a user (actually - the program user's working with), in the multi-user environment, opens a table - is this table opened in the buffered mode by default? If it is buffered mode - what kind of buffereing might be implemented: record level, table level, optimistic, pessimistic, etc.?
(Note: I am not talking about LOCK()/RLOC() functions.)
The origin of the questoin: we have two programs, the prog. #1 (P1) runs the other (P2) and waits until some small table, created by P2, appears in the certain location on disk. And P2 works flawlessly and does create this small Ret.DBF. The problem is that P1 does not always updates its tables with the data in that Ret.DBF. I suspect that, if dBase (Vis. dBase ver. 5.7) opens its tables in the buffered mode, then whatever the method's code does to update this table sits in the memory buffers and never is written into physical file on disk.

Regards,

Ilya

 

[fishmahn]

What you're asking is a function of the network's OS. I'm not sure dBase has any control over it. You can try to use the Flush() command, but I don't recall if it was working properly in VdB5.7. Also, make sure P2 closes the file before P1 tries to read the data.

Mike.

 

[IlyaRabyy]

Yes, colleague Mike, it was in part related to the network performance. You might have noticed that sometimes, when you copy a file from a disk over a (slow-ish) network onto another disk, the file on the destination directory does appear, but it's size is zero bytes in the beginning. The P2 did everything right (and yes, it does close that Ret.DBF file). The problem was that P1 was trying to grab this file at once, without waiting it to be filled out completely, hence the problem.
Once I figured it out and gave my recommendations to the P1's programmer (I'm responsible for the P2), the resolution was found: it boiled down to giving the network to finish off copying the file - and the system started working as it was supposed to.

Thanks!

Regards,

Ilya