>>As I could understand all you do is to get a cursor via ADO and use it in DataGrid. You could directly set your ADO control to use a VFP table or FP2.x table. Then you wouldn't need a VFP COM DLL. Also you could use VFP ole automation (check FPOLE.DLL).
>>Cetin
>
>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
Take a look at batch-updatable recordsets in ADO. Using one of this you can even do the data entry and editing in the VB grid and once you're done you pass the recordset back to the VFP object where you re-connect to the data source and all you do is execute the UpdateBatch method of ADO and all your adds/edits/deletes get comitted to the table.