It is slow, just like moving sand with a briefcase is slow. I agree, now that I understand things better, that this is not the fault of XML but rather the fault of how I was trying to use it, but there is no arguing that taking 1.5 minutes to process 4800 records is slow. I never said it was poorly implemented in VFP. I don't know enough about it to make such a judgement.

My post was simply a result of frustration because in all the hype about XML, I never heard anyone say that it only works if you have a handful of records. I'm not saying no one ever said that; simply that I never heard it. So I went into this with the mistaken belief that XML was good for moving data between objects.

Anyway, I started a new post on how to better do this and got some wonderful answers, so I don't need to worry about XML anymore.

Michelle

>XML is not 'slow', and stating that it is 'poorly implemented' in VFP is being narrow minded.
>
>XML is simply not designed for the quick transfer of data of the proportion you are using. If you try to move a dumptruck-load of sand using your briefcase, it's going to take you a while. Your briefcase, however, is much better suited at carrying business papers than a dumptruck.
>
>XML by it's very nature is bloated, and parsing it using XMLDOM (as VFP does internally) requires loading every node into memory. There are faster ways of parsing XML (read: SAX), but you have to write special code to do it, and it's much more complex. Parsing smaller datasets, is for most purposes practically instantaneous.
>
>For a recordset of the size you're describing, you'd be better off passing a filename around and letting each process access the file directly...