Re: [xsl] Problem with rendering of &#160

[Mike Trotman <mike.trotman@xxxxxxxxxxxxx>]

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.trotman@xxxxxxxxxxxxx] 
> >    
>
>  
>
> > 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 
>  

--
Datalucid Limited
8 Eileen Road
South Norwood
London SE25 5EJ
/ tel :0208-239-6810
mob: 0794-725-9760
email: mike.trotman@xxxxxxxxxxxxx
/
UK Co. Reg:   	4383635
VAT Reg.:   	798 7531 60