Does anyone knows what CURSORTOXML() does in the background that would explain the following behavior? As I posted in some other messages, we are having some extremely bad behaviors with our Web Service in regards to the XML conversion. In the last few hours, I was able to get a better idea of what is going on.

If I call the COM object of the Web Service directly, it works at 100%. So, all is ok there. However, if I call it by the use of the Web Service, I will get some unexpected behaviors but only if I build my XML manually, thus without the need of CURSORTOXML().

Here is the fact. When building our XML, if I build it using CURSORTOXML(), such as CURSORTOXML(ALIAS(),'lcHtml',1,48,0,'1'), the Web Service will process RETURN STRCONV(STRCONV(loXML.XML,1),9) ok. If I built the XML manually, the Web Service will choke on the RETURN STRCONV(STRCONV(loXML.XML,1),9) command randomly. It depends on the lenght of the XML string. It is not related to the French characters of similar. For a test, I replace all my field values with the A letter for the length of each one. This didn't change anything. However, I wanted to make sure it was not related to a special character that the STRCONV() would have choked on from the Web Service environment.

And, more, if I keep trying to run the client program in successive repetitions, about one time out of 10, it'll work. No change anywhere - just rerunning the program. But, the smaller the XML string, the better the chance to have it running ok. If the string is bigger, it'll almost never run.

So, my question is, what does CURSORTOXML() in the background does that would make it bullet proof against the STRCONV() command as oppose to building the XML string manually. Basically, I am making use of the MSXML.DOMDocument to create my XML string. Also, if I test it in a file, the file is always created ok and ready to be used in IE. However, when within the Web Service environment, it'll choke on the STRCONV() command with that approach and will always work ok with CURSORTOXML() approach.