>OLEDB is not tied to, or part of .Net, it's a separate technology. .Net can make use of the VFPOLEDB provider, in much the same way it can make use of any other OLEDB provider.
>
>The VFPOLEDB provider is part of VFP, not .Net, and can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyId=E1A87D8F-2D58-491F-A0FA-95A3289C5FD4&displaylang=en
>
>My understanding is it's pretty complete, it can be considered the data-processing "guts" of VFP. IIRC either VFP help or VFPOLEDB help/readme explains what is or is not available.
>
>I believe the stability to be pretty good. However, owner of this site, Michel Fournier, used to use it and ran into occasional problems under heavy load that were never resolved. Based on his experience, the provider may not be suitable for 24/7 use on a server, but as a local desktop DB it should be OK.

Exactly, if no work as been done in that direction yet, I would definitely recommend to avoid using that provider over the .NET layer.

Common problems:

Occasional unknown timeouts
Error messages given on situation that are not even related

Here is the comment and the list:

' The VFPOleDb provider can report the following bug on SQL commands on random basis
' This happens at every few thousands hits. Normally, issuing a retry will do it.
' This happens only under the IIS layer.
' The errors reported are:
' Field name is a duplicate or invalid.
' Index does not match the table. Delete the index file and re-create the index.
' SQL: Column '' is not found.
' Command contains unrecognized phrase/keyword.
' Syntax error.
' Variable '' is not found.
' Function name is missing.
' Unrecognized command verb.

Microsoft came in with a solution to workaround it. However, I gave up trying to implement that as this was way out of proportion for something that should have been fixed inside the provider directly.

The solution: a move to SQL Server at the same time a move to .NET is expected