>>>The question is would another operating system, such as Novell, respect it? That answer we don't know. Further, I also have doubts on VFP doing it in the first place. Through FPW 2.6, Fox did its own internal caching of reads and writes. Has this changed? I can't definitively answer that question. However, unless some authoritative source says that it has been changed, I must assume that it hasn't. The internal caching was done for performance reasons. Since there's been no out cry that it's degraded since that time, I must work from that supposition. So, from my POV, this represents an additional factor in the latency problem.
>>
>>
>Peter,
>
>>I'm not sure whether you are referring in the above to my expressions earlier (about Novell vs. NT). If not, try to find it (early hours today).
>>Further, in that expression I thought of mentioning the cacheing of FPD as by you referred to right now; this was already there in FoxBase, and I think in FPD 2.0 the REFRESH TO n,N (second parameter) started being there, fully operable (learned from the Fox Software guys back then). One thing I know for sure :
>
>I read your post, but wasn't referencing it directly. We run Novell here as well and I'm aware of some of the problems associated with it from personal experience. In fact, I don't use and refuse to use Novell's Client 32, opting for the MS Client for Netware Networks.
>
>>We have an app in FPD 2.5 very well documenting all of the cacheing behaviour (some 10 years ago). It was just over two years ago that I encountered a difference in the behaviour of indexes (and cahcheing etc.); I don't know when this change really happened, but I assume in some client-version of Novell.
>>Another thing is, that we ourselves use MS-client on Novell (5.x) server, and that the behaviour on indexes is the same right now as it already was two years ago. This behaviour is encountered as negative i.e. "not so decent" or however to explain this in one line (I don't mean unstable).
>
>So now with the MS Client the behavior is again decent as opposed to not so decent or am I mis-reading you? I don't think I am and am interpreting it to meaning that once again you're experiencing the behavior you'd come to expect.


So off topic :
Haha, wrong George !
No, I just wanted to make clear that Novell client and MS client behave the same, IOW as "negative". I didn't like to be more extensive, but here is my explanation (for what it is worth) :

First we all had Novell and the Novell client.
Than we had NT-server and the MS-client. And oops, NT became leading, IOW forcing to let the Novell client act like TCP/IP needs etc.

IMO MS-client (maybe started at W95) changed some cacheing logic, implying the by me noticed change. I noticed this lateron, because we just had Novell, and no new client needed. Two years ago we did, and now Novell client adapted to MS client (TCP/IP reasons let's say).
Now we started buying Citrix-, Internet-, Mail- and some more servers, and created the firewall out of the TCP/IP - IPX/SPX separation. So, Novell for the database etc., and obviously NT for the other servers (I think there is Linux too somewhere). Anyway, this (firewall) didn't allow for Novell client, so we have MS-client. Not usual, but it works (have a separate PC for NetAdmin etc).
The change noticed two years ago now appears to be in MS-client too.

The problem (change) in very brief :
We use a Set Refresh of 60,60 and gain obviously much much performance on it.
Not decent ? true ! Well, fuzzing around with RLocks and some more stuff, this all can be made waterproof benefiting from super-speed on one hand, and all being actual on the other hand (Walter, remember the thread ?).
The change we encountered is that suddenly there seems no normal anymore to commit a change (Replace) to the server. Or ... to let the reading PC see it. So, the latter is true, and the only thing helping is the Refresh setting to 1,1 (never mind which of the both does what). I hear you say : yea logic. And according to all docu, yes it is. It is all confusing, because an RLock just refreshes the data and no problem. However, once you dive into the differences on Skip, Sum, Go, Go Bottom etc., you will see that the one refreshes the data, and the other doesn't. Now HERE some things have changed, and the logic in uour app dealing with this kind of stuff suddendly had to use Locking in order to get the data actual (or set Refresh to 1,1). So, in the end no problem at all, but the app slows down even by the Rlock (refreshing the complete datablock, and not only the one record you need).

With this change, at the same time something changed upon the reponse on an RLock() giving .F.; earlier this took 6tenths of a second, while right now it is as fast as a RLock giving .T. And no, this is not about the various SET's involved with this; it just changed (into the positive this time).
This one is rather complex, having to do with ON ERROR (on something) and some more things which seem not related (but are documented).

I am pretty sure that the MS-client causes it, or maybe just W95+;
These things are about multi-tasking on the one PC as well, and in the Dos-only days this just didn't exist.
I extensively tested all kind of these things on one PC as well (two VFP tasks) and there is no difference with a real network at all. This tells me it is the PC's OS arranging it, giving through to the disk-system (okay, other task) or not, and allowing to read from the disk or from cache. So, Win is in between there and nothing can help that. BTW, very consistent by itself.
Whether a client really influences on this I can't tell, but the only thing I can say is that a Novell client has many more parameters on this which IMO more or less MUST be wrong, while all goes via the registry and in fact the PC should be transparent to the network (dealt with by the registry).

Something like this. I hope you can make something of it.



>
>>So, what you do with the answer I don't know, but things have DEFINITELY changed, though not in the existing Fox-box of course. But our world is more complex nowadays.
>>
>Oh yes. I'm speaking of anyone in particular in what follows, but my general impression is that VFP developers don't, as a whole, understand the relationship between the OS and the applications as well as, say, the average VB developer. Then again, it's just a general impression and I know a number of VFP developers to which this definitely doesn't apply.

Think I agree. But look how really difficult it all really is, and just dare to look at the hundreds of pages documenting the subject overhere. I mean, having this real bigger app running smoothly doesn't come by itself at all, and you just HAVE to know all of it. That is, when you want a good response from your bigger app at the same time.
Ho sh.., now I think of it ...
Jim, I have another argument for your same wishlist :
We really run out of the number of open files a stupid PC allows at one time. THIS argument may be more important than all the others !