>We're trying to run a test case to see if it is practical to combine Visual Basic forms with a VFP middle tier to handle all data operations.
>
>We have written a VFP COM object where we have defined a couple of simple methods to retrieve data from VFP tables.
>
>In the first instance we wrote a procedure GetClientDetails() which creates a cursor (using SQL SELECT) to retrieve data from a Customer data table. We then create an instance of the VFPCOM server and then use the CursortoRS method to create an ADO recordset. This ADO recordset is then returned by the procedure.
>
>In Visual Basic we have a simple form that creates an instance of our COM object and then calls the function GetClientDetails()which returns the recordset. All this works well and we manage to display the data in a VB datagrid.
>
>OK, so far so good. However all this is read-only.
>
>The next step is to find a way to update the data from VB, but this is where we are hitting a brick wall.
>
>In our VFP COM object we replace the cursor by a local view and then use the CursorToRS function to create an ADO recordset which is then returned to VB. This fails during execution; the recordset is not created.
>
>The question then is: how can we create a recordset in a VFP COM object which can be passed to VB and updated from VB??
>
>Looking forward to any suggestions!!
>
>cheers,
>Alain Legrand
>FinancePlus Software, Sydney

Hi Alain,

Why don't you try using a disconnected recordset? I don't use them with VFP tables, so I don't know if there are any serious pitfalls, but I use them all the time with SQL Server. That way, you bypass the VFP cursor and just pass the recordset to VB. There is good info on this method in John Petersen's whitepaper on the Microsoft site.

There are problems in the VFPCOM RSToCursor method. It will return empty cursor fields if the target recordset containins certain numeric data types (I've forgotten just which types). Anyway, the real power in VFPCOM is the ability to bind to foreign events. You can easily construct your own code for building cursors and populating controls.

Another method to look at is using Microsoft Message Queue as your interface to VB. It adds complexity on the installation and maintenance side but it really disconnects the user interface from the rest of the world. The software implementation works well in both VB and VFP and is fairly simple. HTH - Bob