I'll e-mail your message to our network admins. I actually showed it to one of them, and instead of "go figure" he said "I don't buy it". Go figure!

>Just check the windows event logs for "delayed write failures" if they are recorded you have to disable disk write caching.
>It amazes me that the users just ignore this windows message, but later ring saying that data is missing.
>After checking the and finding delayed write failures in the windows event logs, I ask why they didn't ring when they got this message and their reply is usually "I didn't think it was important".
>
>Some time ago I speced a server for client which was eventually supplied by others, the server had U320 SCSI's in a RAID10 configuration, the system ran well for about 12 Months until we started getting failures during our maintenance routines, this took a while to figure out what was going on, as the other hardware supplier had added an IDE HDD as a backup device which had write caching enable and this was causing delayed write failures in the RAID Array, go figure.
>
>>>>Do you know when you'd get duplicate keys with autoinc?
>>>
>>>It can happen if disk caching is turned on, that is another reason to turn it off.
>>
>>We danced around this issue in the past, and I found that:
>>- I couldn't prove that caching is the reason.
>>- I don't know how many levels of caching are involved, and if all can (or need to) be disabled. The only one that we tried to disable in the past was "write caching on the disk" - I say "tried to" because that cache is enabled by default on new computers, and people that install new computers don't always remember to go and disable it. One reason they don't remember is that because we could not prove disk caching cause problems, disabling it was a "soft" policy.
>>What caching are you talking about, is it on WS or on the server? Do you have a test that can prove caching creates problems?
>>If I could, I would disable ALL caching, no, I would ban it!