[continueing]

>Peter, of course Fox does it, and on occasions it gets it wrong and forgets to report that it found an error.

So here we are.
Now assuming that the real native VFP DML is used, I still agree. But what's the cause ?

Skipping the hardware-like problems, I still assume it to be true.
But, to my excessive experience, sure not in the normal environment with proper settings. And it is just here were the difficulties lay;
When looking at the cacheing facilities of the client-software, this is (IMO) cause number one to let flaw it all. The ones from FoxBase know it :
Without any of these nowadyas beatiful facilities, Fox could do it all itself already. I mean, back then we had MS-Dos only, and no Windows. What a time that was. Back then (around 1986) Fox was able to read-cache as well as write cache, and the means from then are 100 % the same from todays VFP. Really.

Right now we have some layers in between VFP and the raw PC. We call it the Windows-OS and we call it the client-software. What a life.
Each of them influence negatively, and if I were MS, I'd start to let VFP bump trough these facilities, no matter what reasons exist around being compliant and whatever. Including the facilities it just does not work. At all.
As mentioned in the "Fox for sale" thread, VFP does not comply from its basis, and it probably can't be adjusted. And when it's doen (to this respect), we'd probably dealing with some factors of lower response.

Now someone found it handy to put another layer in between it, for now desribed as "TableUpate". Beautiful, but then let know that this is for single user systems.

I won't say I know it all, and you may shoot me whereever you can. Please remember, I am always ready to learn, and in fact, by thinking you know things, you were obviously open for learning. So I am.
It may just be possible that I have encountered more anomalies than you out there all together. This is obviously because our system runs in the larger environments, at over 100,000 daily transactions, against the limit of the PC's handles, with all users out of sight/control, and ever subject to some departments' main decisions on configurations because it's about legacy systems here. Don't think that we are able to prescribe configuration rules !
Think of it :

You'd have one big app doing all the work for any of the employees within the company. No matter whether it's about CRM, Financials, Ordering, Orderpicking, EDI, Internet, Workflow Management, Telebanking, but also Printing, Authorizations, Buying PC's they like, Printers the same, using Citrix for all, using client-software as wanted (not knowing anything about that obviously), and using any kind of network-OS opposed to all they'd do at the client's side. Think of it as this environment being subject to about half of the probs mentioned at UT here.
It really, really is like living on another planet.
Ever heard of just printing causing corruption ? Well, I did. It just needs some combination of wrong client settings.

The above just tells one thing : many of the fashioned tools just can't be used, because it urges for problems. All must be used with great care, once you know that the environment where it is used is out of your control. Also we talk "packages" here. Hence, the prob of the one, can't be solved by causing two for the other.

So in the end this all was about putting it in some other perspective, and not because I like to argue things or want to be right ever (though some say it's in me by nature ...).

[to be continued, last time]