>>>>Wat's that about latency ? Do you mean the disk write latency ? Yes of course, we still have this problem in all VFP applications. I don't see this as an attempt to get a full featured database server.
>>>
>>>Hi Walter,
>>>
>>>Don't want to go off topic, but what is it with this latency ? I know what it is technically, but don't recognize any problems with it with respect to VFP. Could you briefly explain ? Thx.
>>
>>Latency has to do with physically writing changes to the medium (hardisk). Harddisk have to ability to chache the writechanges while the OS thinks that they're already written.
>>
>>Walter,
>
>I don't know that "latency" is the correct 'technical' term for this delay between caching and physically writing data, though I agree that George's use was certainly with that intention.
>
>My understanding of "latency" has to do with the delay inherent in getting exact physical spot (record position, I suppose) of the cylinder under the read/write heads so that the correct data can be read OR the data can be written to the correct spot.
>I also understood that "seek time" was the delay involved in placing the read/write heads at the correct cylinder in the first place.
>
>Cheers,
>Jim


Haha. Well thanks. In between the messages I learned what anyway George means by it, and that's enough.
Well, the latency as I know it (referred to by Jim) is about older harddisks having to "rest" once in the somuch time in order "to get by" things. Therefore such a disk cannot be used for CD-burning being a real-time continu process. BTW this latter is obsolete as well, where Plextor introduced a solution to enable this realtime continu process to interrupt.
Something like that.

Since I know now what George means, it is my opinion that SQl-Server (etc. ?) *may* deal better with this problem; Please note the following :

With experience on native VFP tables only, I am 100 % sure that any Novell server has this latency problem. Now note that where I say "Novell server" I must include the Novell Client as well, being the most influencing part of it all (f.e. allowing for very wrong parameter-settings).
With the 15 years experience over all customers having server-crashes once in a while, this may - or just will result in inconsistent stuff in dbf as well as cdx. Cdx is not too much of a problem (well ...) because of the possibility of reindex, but the dbf is. Off topic : there is no consistency by itself which dbf looses how many records being appended in the past 45 minutes. I mean, when 100 users appended 1,000 records across 200 tables, the one table may be complete, and another incomplete for the new records of the past 45 minutes.

Now the clue :

When NT-sever started appearing, customers started using that. In all these years that our according customers used NT-server (for our app), NEVER occurred any "corruption" (read : inconsistency or data-loss, for sure this is no corruption) of any kind. So, not even in indexes. Strange huh ?
One thing : never perform a clear resources because then you are in (the same) trouble.

So, not knowing about these things technically, my conclusion is 100 % (just too much experience) that all so called latency problems are caused by the server-OS or (the combination with) the client. And NOW we can have stories about SQL-server not having this problem ... always running at NT-server and a MS-client.

I dare to say that VFP just doesn't have this problem once the tables reside on and NT-server machine. And mind you, those crash too.
Also look at the next interesting :

We all know of "don't switch off the PC";
We all know too how much throughput time it takes to let our users understand this. New customer ? there the phone is ringing.
Now we have this new customer using NT-server. No telephone ...
Conclusion : NT-server (I don't think that can be the client) allows for PC's just getting powered off, and deals well with the rest.

So, whether SQL-Server allows for explicit parameters in order to avoid this latency-problem, it's okay with me, but as long as VFP-tables reside on NT-server (as well !), there these parameters appear to be used automatically.

Note : The above of course says nothing about a crash of the server being in the middle of a transaction, which IMO SQL-Server (etc.) should deal with better by nature (transaction based -> Walter's log).

My 2c on this, or 1.