You're on the right track Alain. The recordset passed from VFP to VB isn't updatable, because the recordset isn't linked directly to a table but to a COM. And if you think about it, it make sense since in a 3-tiers application, the presentation layer shouldn't talk directly to the data, but through a business layer. So you have to pass back an ADO recordset to the business layer.

I agree it is a lot of work, but you gain in flexibility.

---

>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.