Thanks Tom.
I'm pretty sure it's just the Windows specific characters that are
causing the problem - and aren't encoded properly.
(It was just one or two specific characters producing the errors.
If I deleted these - then everything worked OK.
As I said before - I naively expected a totally-MS processing stream to
produce something that MS ADO was happy with.
It looks like the adPersistADO option has a false encoding expectation
which is not enforced
and just acts as a bolt-on step at the end - rather than a proper
attempt to produce a well-formed XML document.
The only full solution I could think of was to check every record for
legal / illegal characters (once I had established what these were)
and convert everything before persisteing.
But that would have taken a ridiculous amount of time.
Although I found a few MS KNowledgebase articles that seemed to say that
was exactly what you had to do.
I have destroyed the problems files (so can't recheck exactly what the
characters were encoded as)
and told users not to enter anything they can't type on a keyboard.
I wonder if Access 2003 will produce the same problem - or whether it is
more XML compatible?
Passin, Tom wrote:
From: Mike Trotman [mailto:mike(_dot_)trotman(_at_)datalucid(_dot_)com]
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'
[code snipped]
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).
You should check to see what the characters involved are. If, for
example, the Access database contains CP-1252 (Windows-specific)
characters, which is not uncommon, they will come out all wrong in
iso-8859-1 or utf-8. So you need to find out whether the problem is that
the declared encoding of the output does not match the actual encoding
(like utf-16 instead of utf-8), or whether it is just those characters
that aren't encoded or escaped properly.
Other than that, someone else will have to help with encoding issues
with ADO and perl, because I am an innocent in these areas.
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