>>>>Al,
>>>>
>>>>In a scenario where FP2.5 code is running under VFP8 and the only technique used to prevent multi-user collisions is to occasionally set a lock on a record being edited in the form. No transactions, no buffering except for whatever is default, no nothing. Totally optimistic approach.
>>>>Well, in the days when this was an ok way to use Foxpro, somebody found that write-behind caching should be turned off. Only we can't remember was there anything foxpro specific in the reasoning.
>>>>Now, as you say, the OSs are different, VFP is different, equipment is different.
>>>>Only code, unfortunately, is the same.
>>>>Do you know anything that still applyes to write-behind caching and the kind of programming style I described?
>>>
>>>Programming style under VFP makes no difference. If your environment meets the specs for server and workstation I outlined at the top of my last post I'd leave write-behind caching (WBC) on.
>>>
>>>At the bottom of my last post I listed 8 things that, in my real-world experience, cause more corruption and data loss problems with VFP apps than WBC. Make sure that none of them are issues in your environment first if you want a reliable networked VFP app.
>>>
>>>After you do that, you can certainly still turn WBC off if you wish. The tradeoff is that you will certainly reduce system performance, for a slight reduction in the chance of data loss or corruption in the event of some sort of catastrophe.
>>>
>>>If the cost of data loss or corruption is high enough that it's worth turning off WBC, you should probably be looking at storing your data in a repository that has inherently higher fault tolerance such as SQL Server.
>>
>>I've just gotta intervene here...
>>
>>If one actually went to SQL Server for those reasons then they are told by SQL Server support (unless they have that expensive battery-on-board HD adapter) to TURN OFF write caching!!!
>>Quoting from "Inside SQL Server 7.0":
>>"If a controller cannot gaurantee that the write will untimately be completed, you should disable the write-back caching feature of the controller or use a different controller. Disabling write-back caching in an I/O-intensive emvironment (more than 250 I/Os per second) might result is a SQL Server performance penalty of less than 5 percent. ... In a less I/O-intensive test, the effect would likely be negligible. ... Write-back caching must be disabled or you eventually get corrupted data. This point warrants repeating... " and a little later: "You might expect that using a caching controller that doesn't have a battery backup in combination with a UPS is generally OK if you do an orderly shutdown of SQL Server during the life of the UPS's power. However, this is not always the case. SQL Server support engineers who get customers' servers back up and running can tell horror stories about customers who use write-caching controllers that were not designed around transactional
>>integrity. ...".
>
>It's important to distinguish between Windows' WBC (using system RAM), and WBC as implemented by a hardware RAM cache on the HD controller itself. It sounds to me like the book you quote is discussing the latter case, not the former. In that special case I tend to agree; on a system shutdown Windows will flush its buffers to "disk" before shutting down, but if those writes are being cached by a special controller there's no guarantee they are actually written to disk before system power goes off. Yes, in that case a battery backup of the HD controller cache RAM could be useful.
>
>>So, despite your experiences, I'd still highly recommend disabling write-caching on ANY device except one designed for full fault tolerance.
>
>Again, I assume you're talking about specialized caching HD controllers. I don't think you can conclude this for Windows OS-level WBC which is what I've been discussing all along.

Hi Al,

Wouldn't you say that specialized caching HD controllers are a subset of HD controllers generally?
And wouldn't you say that if even such HD controllers are deemed inadequate for SQL Server (unless they have on-board battery to preserve local RAM and intelligence to empty to HD after failure), that our regular run-of-the-mill on-board HD caches are even less adequate?

I strongly suspect that any "Windows OS-level WBC" has far less attention paid to it than SQL Server itself would give to it.
Finally, why would it be that I do get a Windows OS-level error when I have write cache enabled (consistently, over 4 different HDs and 2 different OSes)? It is true that in every case the motherboard is ASUS for AMD, for what its worth. And when I turn it off the error goes away???

cheers