>Oh . . . well I still don't know why this worked on the production machine and not mine. It was the same exact code and the same exact data. But my fix should work on both machines . . .

A version issue? Are there schemas associated with the XML? The final rendering may depend on a particular XSD and the ability of the DOM version to "consume" it.

It may be the case that that the [production] machine has a newer version of DOMDocument than "your" machine You could check with VFP (or Excel) installed on both machines. A "generic" DOM request does not "default" to the most recent version. Here's some code to test - there may be an easier way through the registry:

ON ERROR oXML=.NULL.
oXML=CREATEOBJECT("MSXML2.DOMDocument.4.0") &&Try an explicit connect to 4.0
ON ERROR  &&point to global error handler
IF ISNULL(oXML) && Can't get 4.0
   messagebox("DOMDocument.4.0) not available")
ENDIF 
* The generic DOM is:
oXML=CREATEOBJECT("MSXML.DOMDocument") && Generic
* I think they go 0-1-2-3-4 - and you may have to test like you would for a "flash" version.

>
>>Yes, it was as I suspected. VFP was creating a field of N(5,0) to hold the value and then when it came across 1325300 for a value, it had to place "1.E+6" in there. Instead of letting VFP create the cursor, I created the cursor as it needs to be and then used the 8192 flag on the XMLTOCURSOR statement so that it would append to that cursor. Works fine now. Thanks for your reply.
>>
>>>I will be looking at this more today. I know that in the XML sent to me, the values are correct. I have not looked to see if the values are incorrect in the VFP cursor I create from that XML. This is really the first opportunity I've had to look at this since posting the original message. But I'm wondering if VFP is taking the original XML and simply not making a field large enough. The reason would be that most of the values in this field are small - 5, 12, 46, 112 small. Then, for some reason, the value I've had trouble with is large (1325300). There's no reason for that, it's an identifier and they had been using an incrementing number so they were up into the hundreds, I think. Why this identifier is suddenly so large is beyond me, but I'm wondering if VFP is assigning the field size without consulting all values, then it turns out to be too small. Similar things can happen in an SQL statement.
>>>
>>>Thanks for the reply.
>>>