There is a performance hit because you have to go through the ODBC Driver and that's going to be slow. However, I don't know (as I have never tested it) what the performance benefit/hit would be to generate a VFP cursor in a VFP COM server and transform that into an ADO recordset using the VFPCOM method, CursorToRS. Perhaps, JVP (or someone else) has.

>Don't you get a significant performance penalty for using ADO to access VFP data?
>
>>I'm not sure of the added benefit of inserting these commands in a VFP COM object (unless you want to add COM development to your web development resume *s*). You could do the same thing within the ASP code itself:

>>< % set conn=CREATEOBJECT("ADODB.Connection")
>>lcOpenstr="driver=Microsoft Visual Foxpro "+;
>>"Driver;Exclusive=No;sourcetype=DBF;sourceDB=Mydbc;pwd="
>>conn.Open(lcOpenstr)
>>csql="Select field1,field1 from mytable"
>>set rs=con.Execute(csql,,1)
>>
>>DO Until rs.eof
>>   response.write(rs("field1"))
>>   response.write(rs("field2"))
>>loop % >

>>
>>>You must create a VFP Com object. The COM can have the methods to return values or recordsets, or you can pass parameters to insert or update records.
>>>
>>>
>>>You COM object can be:
>>>
>>>Define Class myProcess AS CUSTOM OLEPUBLIC
>>>Function mydata
>>> conn=CREATEOBJECT("ADODB.Connection")
>>> lcOpenstr="driver=Microsoft Visual Foxpro "+;
>>> "Driver;Exclusive=No;sourcetype=DBF;sourceDB=Mydbc;pwd="
>>> conn.Open(lcOpenstr)
>>> rs=CREATEOBJECT("ADODB.Recordset")
>>> csql="Select field1,field1 from mytable"
>>> rs=con.Execute(csql,,1)
>>> Return rs
>>>Endfun
>>>EndDefine
>>>
>>>Compile as Myserver
>>>
>>>In the ASP
>>>SET oVFPclass=CREATEOBJECT("Myserver.myprocess")
>>>' call the function
>>>SET rsRecords=oVFPClass.Mydata
>>>DO Until rsRecords.eof
>>> response.write(rsRecords("field1"))
>>> response.write(rsRecords("field2"))
>>>loop