Thanks Paul. I'll definitely take a look at this.

I'm surprised that XMLAdapter and XMLToCursor() was built around the XMLDOM parser and not the SAX parser.

Is processing time the same or better with small XML result sets?

>
>If your processing large XML result sets, it's WAY faster to use the SAX parser along with some custom VFP code. I had a large 16MB XML file that I needed to download nightly. XMLTOCURSOR choked on it (to be fair, just loading it into the DOM through the COM object was just as bad). I ended up using the SAX process to handle the file and it now runs in under 30 seconds. Not blazing fast in general, but >much< faster than the alternative.
>
>You basically create an object which implements the IVBSAXContentHandler interface in MSXML2.SAXXMLReader. Then you stick code in the IVBSAXContentHandler_startElement() event to check to identify which field is being processed (and it's field type), and put code in IVBSAXContentHandler_characters() event to update a temporary table/cursor with the field value.
>
>Here's a small sample (I didn't include all of the code)
>
>

>loReader = CREATEOBJECT("MSXML2.SAXXMLReader.3.0")
>
>* Custom VFP object which implements proper interface
>loParser = CREATEOBJECT("myXMLSaxParser")
>
>loReader.ContentHandler = loParser
>
>* Load the XML
>lcXML = FILETOSTR("C:\FileName.XML")
>
>TRY
>   loReader.Parse(lcXML)
>CATCH TO loException
>   * Error
>ENDTRY
>
>DEFINE CLASS myXMLSaxParser AS CUSTOM OLEPUBLIC
>   IMPLEMENTS IVBSAXContentHandler IN "MSXML2.SAXXMLReader"
>
>   FUNCTION Init
>      * Create cursor here
>   ENDFUNC
>
>   PROCEDURE IVBSAXContentHandler_startElement(strNamespaceURI AS STRING @, strLocalName AS STRING @, strQName AS STRING @, oAttributes AS VARIANT) AS VOID;
>      * Add code here to determine the field name and field type, and
>      * add a new record if necessary
>   ENDPROC
>
>   PROCEDURE IVBSAXContentHandler_characters(strChars AS STRING @) AS VOID;
>      * Add code to here to do the REPLACE into our temp cursor
>   ENDPROC
>ENDDEFINE
>