>>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. ...".

So, despite your experiences, I'd still highly recommend disabling write-caching on ANY device except one designed for full fault tolerance.

Jim