I have a similar (and maybe related) problem.
I am using a Perl CGI script on an IIS server with ADO and MSXML.
I perform a query on a (currently MS Access) database containing 'memo'
fields.
when I try to persist the query result into XML
610 my $xml_tmp=Win32::OLE->new($MSXML);
611 $xml_tmp->{async}=0;
612 $xml_tmp->{validateOnParse}=$validate;
613 $xml_tmp->setproperty('SelectionLanguage','XPath');
614 $xml_tmp->setproperty('SelectionNamespaces',
615 'xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"
616 xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
617 xmlns:rs="urn:schemas-microsoft-com:rowset"
618 xmlns:z="#RowsetSchema"');
<snip/>.....
714 $rs->Save($xml_tmp,1) # 1 => adPersistADO
I get an error as the XML is not well formed - containing illegal
characters from the 'memo' field
(one of the ones I found was rendered as a bullet 'blob' in MS Access).
I had (optimistically) expected the ADO persistence to do any character
conversion necessary to create a legal XML document.
Is this likely to be a similar default encoding problem
and could I fix this by specifying an encoding on my target XML object?
Any help greatly appreciated.
Passin, Tom wrote:
From: Richard(_dot_)McMillian(_at_)cexp(_dot_)com [mailto:Richard(_dot_)McMillian(_at_)cexp(_dot_)com]
This thread addressed the problem back in 2002. Has anyone
come across a better solution?
http://www.biglist.com/lists/xsl-list/archives/200211/msg00172.html
Sure, Julian Reschke posted it earlier today. The MS component always
generates utf-16 when you use it to create strings instead of objects.
Thus there ends up being a mismatch between the declared encoding and
the actual encoding.
This is pretty much a FAQ by now, but until you posted your code no one
could tell what you were invoking the problem.
The solution is not to futz around with the meta element and trying to
trick the browser, but the generate the output using objects instead of
strings.
Once the encoding discrepancy is fixed, the presence of the meta element
will not cause any problems and could even be beneficial (as when the
document is loaded from a file, and thus has no headers to state the
encoding).
Cheers,
Tom P
--+------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--+--
--
Datalucid Limited
8 Eileen Road
South Norwood
London SE25 5EJ
/ tel :0208-239-6810
mob: 0794-725-9760
email: mike(_dot_)trotman(_at_)datalucid(_dot_)com
/
UK Co. Reg: 4383635
VAT Reg.: 798 7531 60