>
>You never detailed what kind of object you were returning... a Recordset? And, what's slow? Your conversion routine? I doubt that the COM datatype conversion is causing that much trouble.
>
My data manager receive 2 parameter arrays, one with SQL select statements to be executed, other with a list of the tables to be used.
It opens the tables, executes the selects and closes the tables.
It can handle one or multiple end result cursor(s).

Then I have multiple choices , to convert it/them to XML -thanks for your warning, I'll use Rick Strahl's wwXML class instead-,ADO,arrays,etc; my own method is creating a separator object with custom properties to store cursor name, number of records, an array property to store the cursor structure with afields(this.aCursorStructure) and an array property to store records dimensioned according to the number of records.
Then I'm scanning a cursor, creating an object for each record with scatter name oxx and storing it into the array with this.arecords(n)=oxx.
The end result is an 'table' object with all the cursor info encapsulated inside it.

An extrapolation works too, meaning I can store 'table' objects inside another separator object with an array property to hold each one, to finally have multiple cursors/tables ready to travel encapsulated in one single object which is returned. Lets call it Data Object.

This concept works very well when used in a VFP-only environment instantiating it with set classlib to/createobject, no complains at all.
Getting the table(s) from inside the returning data object by creating cursors and appending records from it is fast enough.

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 (I know because I checked it with the VB object browser).

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.

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.

In summary, everything is sound up to obtain the data object, is VFP after all, the problem is the slowly data extraction when the returning data object is COM.

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.