>Your code, no. The design, maybe. You have returned 200 COM objects to a client process, each with a property for each field...

You are right, I agree, it doesn't work for what it was intended.
On my defense :), I was misguided with the speed in VFP without fully testing the solution as a COM server. I did some little testing initially, exclusively to check if VB was able to 'see' the returning object, at that time a simple single record one...another lesson and counting...

>
>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.

Your advise is the best one I have received up to now, I'm somewhat familiar with everything you told me but at theorethical level only, time to begin testing.
On the bright side, there are 2 methods in my class that need to be deleted/abandoned/put on hold: DO2DBF and DBF2DO; replacing them with Rick's xml methods will be not difficult, I think. I has been looking his shareware code and reading his documents for almost 4 weeks and boy, I had learned a lot.

Again, thank you very much Erik, I'll tell you about this soon.

Agustin.