Nope, the only way is to use standAlone N and then add the xml "header" and "footer" yourself. Point taken, there's gonna be a switch in the next version to turn this off.

Hi, is there a way to avoid this in here <root DATE_CREATED="2005-04-12 18:54:15" CREATED_BY="Microsoft Log Parser V2.2" > I would like to get this just like this <root> makes life easier on the further imports with .net unless there is an easy workaround in .net itself because of the date_created...

Gabrielle you are a wonderful person, many thanks for this, it worked perfect, we were looking codepage not ocodepage. once again thanks for the reply all the best simon

Set oCodepage to 65001. That's the Windows system value for UTF-8.

Hi Does anyone know how to switch the encoding of an XML file to UTF-8. It currently stands at ISO-10646-UCS-2 and I looked at the codepage setting but I think its choosing a system default and I can't seem to change this. many thanks simon

I have a report of Intrusing detections that outputs the following text to an XML file. <?xml-stylesheet type="text/xsl" href="Table.xsl"?> <ROW> <Messagetxt> HTTP_BAD_RESP_MSGHDR </Messagetxt> <Total> 567 </Total> </ROW> I have a second XML file that has additional...

There's a "compact" switch in the xml output format that removes the CRLF's and spaces... ...this said, 1) the new line characters should actually be CR+LF (0x0d 0x0a) and not 0x0a alone...are you piping the xml somewhere? 2) I can't see how the MSXML would choke on these extra characters, unless the...

Itis unfortunate, because if I want to use a program to XPath query nodes in the list, it doesn't seem to find the specific nodes..... For example, the xsl: <xsl:variable name="EventType" select="."/> <xsl:for-each select="/ROOT/ROW[EventType=$EventType]/SourceName"> .......... </xsl:for...

Same thing here, but why is it unfortunate? I would guess it's for human readability. Shouldn't matter if your using an xml parser or xsl to format the result.

I am using LogParser 2.1 and sending the output to XML so I can review the results. Unfortunately, it appears as though LogParser (or perhaps the underlying log) is generating linefeed character (0x0A) and two spaces after the contents of each output. I have conducted testing on this and the CSV output...