>Wouldn't you rather work with VFP data cursors using the VFP language rather than working >with ADO recordset objects? I'm still not sure if you want VFP data/language capabilities >using COM based ADO recordsets, or if you want to be able to use VFP data/language >capabilities from data retrieved via ADO. Let me know. I may be offline for several days as >I'm off to DevCon later tonight and I have a few things scheduled to do there and kind of >busy at times. :)



I love VFP. I think it's the best data tool on the planet! I think
the data capabilities are unmatched.

But I also have come to appreciate ADO. I really like the
ability to pass a recordset as a parameter. The closest
VFP comes to that is SCATTER NAME ObjectName. But ADO has
the funtionality built in to update, and transactions.

I like this because I do some work where I manipulate data in
various DLL's, both in VFP and VB.

If I SCATTER NAME oRecords, and then pass oRecords to some
function in VFP, I still have to have a GATHER statment somewhere
to save the changes, but if could create an ADO recordset,
and I passed that recordset to VB, then VB can do what it wants
with the data set, including update and use transactions.

Think of it this way:

PROCEDURE MakeRecSet
LPARAMETERS cCursor

  LOCAL oRecordSet, oVFPCOM

  oRecordSet = CREATEOBJECT("ADODB.RecordSet")
  oVFPCOM = CreateObject("vfpcom.comutil")

  SELECT (cCursor)
  =CURSORTORS(oRecordSet, cCursor)

RETURN oRecordSet

I'll check back with ya at DevCon!