I can use complex queries that consist of multipl tables + computations via adodb.connection + adodb.recordset to show on an Activex Hierarchical Flexgrid. And ado connection doesn't drop memo fields. OTOH VFPCOM's Cursor2RS() also doesn't drop memo fields (drops general). I think you could use one of these in ASP (BTW I used the first approach directly in VB too so I think it's applicable - for a sample check related message I posted to Lal Senanaya yesterday or the other day - title similar to 'How to access VFP data from VB').
Cetin

>Seems that we are always running into this problem. We need the power of VFP's engine to create a cursor that might be derivative of several other tables plus various (and often interative) manipulations of the data along the way. And we need to get the contents of that cursor onto the web. One way, for sure, is to send the Response and Session objects from ASP into VFP, use VFP to generate HTML, and use Response.Write to transmit the HTML. But I would prefer to use VFP solely as the data engine and use ASP for session management and HTML generation (yes, I know it's slower, but there are internal reasons why we prefer to use ASP as the core technology for the application's presentation layer).
>
>>>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