>but when I compiled the thing as a COM server, the returning object was a legitimate COM object with every piece of data inside as variant type. Accessing the information from a VFP app was way to s-l-o-w. I guess it's because the whole vfp data type-variant-vfp data types conversion.
>

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.


>I had not tested it with VB yet (I'm not really VB-literate but I need the UI in VB) and I'm wondering if you can give advise on the issue, what is the fastest method to share data VFP-VB-VFP?

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.

BTW, the dbf->xml->dbf routines in the Ken Levy's xml tool are not really practical to do any real work with. They don't provide for any datatyping, so converting back from XML turns all fields into memos. For a really great tool to do this right, look at Rick Strahl's wwXML class at www.west-wind.com.