>>Before, the client was using a direct map drive shared to insert and update data into another server. In such a situation, the client reports that several corruptions happened when specific PCs were doing some inserts and updates.
>>
>>In the actual setup, we have a .NET Web interface, several .NET desktop applications and several .NET Web Services that are located on various servers which would all use the same backend located into a dedicated server serving that purpose.

So here you now definitely eliminated client HW problems you could have had before. By having a singular point of failure you lessen this risk greatly (read power of probability of running all clients without failure equals [nearly] the probability of "no problem").

>The backend is still Visual FoxPro. For our first phase, it is expected that the backend remains Visual FoxPro. In all those applications, the data provider is OleDb.
backend as in "dbf" file format or vfp-runtime based service ? Also, is the backend service handler on the same machine as the tables ? *That* is the architecture I'ld advise, from perf to security.

>>If we keep that design, is there any factor that could cause data corruption such as when it was happening when the previous versions of several applications were using a map drive for the data access? Basically, are we in better shape to avoid those situations now?

Since the earlier problems were not clearly identified, hard to say <g>. vfp still has troubles with different encodings / unicode, so if you had a problem there, it might linger. I'ld say you are definitely in better shape from HW failure, but if that wasn't the big problem...

>>The client reports that if we would use SQL Server, Oracle of Sybase that the opening and writing mechanism to write to the tables is done from a service which does it all on the server.

This is what I advised as well - lessens the chances of failure immensly. In this setting vfp is getting nearer, but big SQL servers are still more fault tolerant, especially after SOME kinds of hardware/process failure. But the difference might not be that important anymore - hard to tell from here.

>I understand that this prevents those unexpected situations of data corruption. But, this does not apply when the backend is Visual FoxPro. So, is there a way to be safe in regards to data corruption using Visual FoxPro?

As long as the process updating the tables is on the same machine as the tables (be it a .Net service, a vfp COM instance or full blown vfp app/exe in citrix or terminal server) you have eliminated most of the hardware architecture based risks (most because of better use of different disks in some other products enhancing the protection). A small security difference is still there but tiny compared to the risk before. But you also might have a special security gain, since vfp's "obscurity" doesn't make it a viable target for things like SQL slammer <g>. Just let it run get get experimental data.

regards

thomas