>When I compile this thing into a COM server (EXE) it works fine too BUT the returning data object is now a COM object and every piece of info inside is variant type...

Yep.

>VFP was used again primarily because I can use the same code without changes again. Reconverting the tables from the data object is painfully slow then.
>I'm talking about 11 seconds vs subsecond responses for 199 records, my autoimposed return limit. Obviously my code is not the problem.

Your code, no. The design, maybe. You have returned 200 COM objects to a client process, each with a property for each field. If each table has 5 fields, you are crossing COM boudaries a minumum of 1000 times to convert your cursor. I am not surprised that this is slow. An XML solution with a client side parser should be an order of magnitude quicker (depending on your parsing routine), because you are only retreiving one long string from the COM object. With ADO, it might be even faster because you don't have to parse anything on the client side. ADO, of course, would require more conversion time on the server, but that code has already been written for you, and is MUCH faster than your reported 11 seconds for 200 records.

ADO 2.x has the ability to persist a recordset to disk in the form of an "ADO compliant" XML document. Another, empty, recordset can then use that document to recreate the recordset. I wouldn't bring this up except that Rick's wwXML object has a methods that will convert a VFP cursor to a ADO compliant XML document, which an ADO can use later to build a complete recorset from. Getting your cursor into ADO this way turns out to be significantly faster than VFPCOM's CursorToRS method, and definitely faster than Ken Levy's conversion routine. I would check it out, I think you will find testing this method to be a worthwhile direction to take.



>Why I am doing something like this? Well, the idea was to build a generic and flexible component to access VFP data from anywhere and to be in total control without install/depend on ADO/ODBC or XMLDOM on the client side. Then I hit reality.

Yup. Your efforts are valiant, but because of COM overhead, you were doomed from the beginning going down the 'each record as an object' route. COM is relatively fast, but it was just not designed to be used to the extent that you are requiring for this job.


>Hence my question about the fastest method to pass data VB-VFP-VB.
>>
>>If this is the entire scope of the data, then I recommend ADO. It l;ends itself perfectly for getting data across COM boundaries, and VB programmers should already be familiar with the format. The only breakdown is when you need to go more crossplatform, or manipulate data in a browser. COM over HTTP isn't mature yet. For a situation like this, XML is the way to go.
>>
>I'll test ADO and XML conversion speed next week, thanks for your help and time, Erik.