>We are working on an ASP web project. For some of the data retrieval, we are creating some VFP COM servers. It would be very handy to use VFP's engine to create a cursor, convert the cursor to an ADO recordset, and pass the recordset back to the ASP environment.
>
>I noticed that the example that Microsoft provides (DBF2RS)for converting a VFP recordset to an ADO cursor simply converts memo fields to fixed-length 256-character fields. Is this useless or what?
>

>		CASE lcFieldType=="M"
>			lnDataTypeEnum=ADCHAR
>			lnFieldSize=256
>

>Can anybody out there please reveal how to convert a VFP cursor to an ADO recordset in a way that maintains a memo field's full length and all data within it.
>
>Is there not some "built-in" way to achieve this (i.e., provided by Microsoft) rather than having to hand-code a relatively slow VFP procedure?
>
>Thanks very much.

Mark,
Honestly speaking I don't understand the need for DBF2RS and VFPCOM's CursorToRS(). BUT since the author is Ken Levy whom I think is one of the real masters of Foxpro and I respect him much I simply think I can't see it for now.
With my relatively smaller knowledge I would ask why not directly make and ADO connection to VFP tables (either in DBC or fox2x) today with 'OLEDB provider for ODBC' and tomorrow with 'OLEDB provider for VFP'. It's doable in VFP and VB (and doesn't drop memo fields). For some activex controls I needed it and you're right DBF2RS() and Cursor2RS() was slower than ADODB and ADODC connections. OTOH I don't know if making a direct ADO connection is not suitable for ASP or not.
ADO itself is a Fox technology AFAIK. ADO connection is slightly slower than native Fox engine and I understand it uses ODBC. If you run it from VB performance is more impacted. VB simply cannot load data fast either from ODBC or a Jet database (and who in the world could expect it from VB).
Cetin