>>It looks like I'll have to go into more server details than I wanted - I know we have RAID but don't know the type, level, configuration... One of the network guys said that cache is good because it allows the server to go over periods when there are more requests to write than it can serve. I'd accept that is a good thing if the cache keeps track about pending writes and reads from the most recent, not from the disk.
>
>That's exactly the way a write cache is supposed to work. Write caches are most reliable with the simplest systems e.g. within a single computer (CPU write-through cache, local disk write cache etc.)
>
>File-server databases like VFP put a lot of stress on cache subsystems. Some of the issues involved:
>
>- The server must coordinate write requests from multiple workstations that all have the same file open simultaneously. This requires management of file and record locks as well as cache coherency
>
>- Requests from workstations have to make it out of VFP (and any caching/buffering it may be doing), through the local OS caching/buffering (if any), to the network redirector (again with possible caching/buffering), then through the network to the server. So, there are several points of potential failure
>
>- Now add in unknowns like antivirus programs hooking into file system reads/writes and who knows what else (on both workstations and the server)
>
>I think in many cases write-behind caching gets a bad rap. Sure, as Neil points out there are some unusual cases where you can point to problems with specific equipment, drivers or implementations but I don't believe they're common - MS could not afford to turn on write caching by default if they were. With multi-user VFP apps I believe it's important to ensure workstations and network infrastructure are reliable before changing global server settings.
>

If autoinc require 2 round trips from WS to the server (1 to get the current value, and second one to write the incremented value to the header) then it seems to me that network speed combined with VFP data engine are the problem, not caching on the server.
If it is just one trip, then it is the cache on the server that fails. The speed of the network and WS different levels of cache shouldn't matter.

>A lot of servers these days have fast CPUs and tons of RAM, so they tend to be disk-bound in performance. Some disk subsystems such as RAID 5 tend to have relatively poor write performance so they really need write-behind caching. Turning it off affects all processes on the server, not just VFP writes. It may be that VFP use on a given server is only a few percent of what it's doing, and admins tend to take a dim view of penalizing the other 90-odd percent of the processes just to coddle one.
>
>In general I'm a big fan of caching. I believe that, fundamentally, they're an elegant implementation of Pareto's Law.

Well, if you are talking about fashion, then elegance is important. For database applications a 80/20 success rate distribution is a disaster.