>The reason we don't want to use an ADO control connected to a VFP table is that we want to keep all the data operations and business logic in a VFP COM DLL. We want the VB form to not have any knowledge of what the data tables are (VFP, SQL, BDE, whatever). The VB form receives an ADO recordset and operates on that.
>
>Having thought more about our problem I think the issue is that the CursorToRS function creates an ADO recordset which is disconnected from the original cursor. So even if the original cursor is an updatable View, any changes made to the ADO recordset will not pass through to the View.
>
>My guess is that the only solution is for our VB form is to call another routine in our VFP COM DLL (say, UpdateCustomerRecord() ) and pass to it an ADO recordset that contains the changes made in the VB form. The UpgradeCustomerRecord procedure takes the ADO recordset, converts to a VFP cursor, does some data validation and then updates the back-end table.
>
>It is more work than I thought we would have to do but it is all we can think of right now.
>
>The goal is to make the front-end totally independent from the back-end, yet still have the power of VFP for data handling.
>
>Alain

---

Seems you will have a hard job. I really don't know how I could assure data reliability when VFP is in middle-tier. Maybe VFP COM dll would get the data offline.
I would ask myself what VB provides that VFP cannot.
Good luck.
Cetin