>Hi:
>
>I'm thinking of using ADO.net against the VFP OLEDB provider for some simple data access stuff where a COM object would not be justified. I've seen many people in here complaining about problems with it. Is it broken? What are the limitations?

I've been preparing some info on this for a session I'm doing in KC, and it was painful <g>... I'll post the document when I get done on my site, but there's a bunch more to be done (COM Interop and Web Service Interop).

If you're mainly reading data the OleDb provider works fine. Getting data into a DataSet is easy enough. Unfortunately the VFP driver doesn't support automatic schema retrieval so auto-update functionality is not supported, which means you're back to writing manual SQL statements for all update/insert operations. In fact it takes a lot less code just running those commands explicitly than trying to update a DataSet.

This means that if you look at a book that shows how to use DataSets for updates - that code is not likely to work with VFP OleDb at this time. But if you use SQL commands you can do everything - it's just a little more work (but it may actually be more efficient that way too in terms of performance).

There are also a few bugs with trigger violations causing OleDb errors, yet the data getting written anyway. It's isolated and not that big of a deal if you know what the issue is.

Finally, I did some performance comparisons running equivalent code from a VFP COM componetn and native .NET code using the OleDb driver and the VFP COM object code ran about 20% faster even with several COM object calls.

OTOH, performance was pretty good either way with over 80 requests being serviced compared to close to 100 with the COM object.

Microsoft is aware of these issues and they are working on making the driver .NET compatible but right now it's more work than other drivers and finding the right documentation on what you need to do is not so easy to come by.