Hi Neil,
>Hi,
> In a nutshell all caching & redirectors have to be DB aware, they are not. What I know is, that if you disable the caching, both read and write the DB corruption disappears.

Assuming that you mean "DB aware" in the general sense (in the way DB software does I/O compared to non-DB and/or server based technologies) I agree fully that they NEED to be.
I take it that, from your readings, you too are convinced that Win cacheing is NOT designed for DB-styled I/O. I think we need to get more people questioning this. We seem to have a handful now.

> The performance hit is about 40%, but you can sleep at night, without worrying when the next FPT CDX or DBF corruption is going to occur.

That's interesting indeed. A sledgehammer approach gives a 40% hit. One could conclude (well, I would) that with some work by MS that could easily go to the 5%-15% level.

> In Netware we didn,t get problems until they started to implement OP Locking & client file caching.
> A bit of work by MS could save a lot of headaches.
> Speed is good, but the fastest corrupted database is not.


Yes, and it seems to me that what we need to do is to get people, and most especially MS, to be aware of this so that something cn be done about it.
As I said elsewhere, interest in this seems minimal.

>
> What we (UT Users) should do is, a full review of the requirements to get a stable DBF implementation, with performance hits, then bounce it off MS to see what they have to say.

Yes, that would be wonderful. I guess a fresh new 'starter thread' would help, if only to try to get a wider audience and participation.
>
> If you need any help let me know, we seem to be going backwards, not forward.

While I agree that we seem to be going backwards, I am of the opinion that this has been a problem for quite some time (like since other-system file access was invented) but that it is faster hardware, larger RAMs, more 'endowed' DB software, more proficient (VFP) developers and lesser-proficient end-users that combine in various degrees to make the problem more visible and wide-spread now. Hopefully we can some day soon get to the bottom of it all and have it fixed permanently.

>
>P.S. The reason I gave u the link to the links is that this was a good thread to start something like this from. i.e. get it fixed

Yes, I understood that to an extent. And my thought is to spend some time this weekend dredging up other similar threads and to reference them in a new thread specifically aimed at this issue.

cheers