"Anthony Jones" wrote:

> 
> "Luis Vargas" <Luis Vargas@d...> wrote in message 
> news:AB0F7A56-440C-428E-8240-E7F08B300A01@m......
> > "Anthony Jones" wrote:
> >
> >> This info is for those of you who are using the transformNodeToObject 
> >> method
> >> in an ASP page to send the results of the transform directly to the ASP
> >> Response object.
> >>
> >> The security update 955069 includes a change in behaviour where the 
> >> IStream
> >> passed in the output parameter has its Commit method called where in 
> >> older
> >> version this never called.  The IStream implemention in on ASP Response
> >> object will through an error if its Commit method is called.
> >>
> >> Workarounds:
> >>
> >>     1.  Don't install 955069 (not recommend its a security update).
> >>     2.  Create an IStream wrapper object that delegates to an inner 
> >> IStream
> >> except the Commit method.
> >>     3.  Don't use transfomNodeToObject just transformNode and 
> >> Response.Write
> >>     4.  Send XML and get your client to do the transform
> >>
> >> Option 2 only really an option if you the tools and the control over the
> >> server to implement it.
> >>
> >> Option 3 if you were generating large content with buffering turned off
> >> transformNodeToObject is pretty effecient, with transformNode and
> >> Response.Write you are going to use more memory and will need a buffer 
> >> size
> >> big enough to handle the result (or slice up the result).  You will also
> >> need to consider encoding, where ToObject would have encoded to CharSet
> >> transformNode always returns unicode.  Hence the best approach would be 
> >> to
> >> set Response.CharSet = "UTF-8" (you were doing that already right?) and
> >> Response.CodePage = 65001.  On 2000 SP4 with IIS5 this gets trickier 
> >> still
> >> because the Response object doesn't have a CodePage property, you would 
> >> need
> >> to do it on the session then set the codepage back to its original value
> >> after the Write.
> >>
> >> Option 4 is well worthwhile if you can stand the upheaval but for new 
> >> code
> >> its worth considering.
> >>
> >>
> >>
> >
> > Hi Anthony,
> >
> > Thanks for your help on all this. All the pages in my web site show the
> > error that was not there before. Check it out. www.markallenonline.com
> >
> > I have a classic ASP web site and most of the pages use something like 
> > this
> >
> > Dim objXML1
> > Dim objXSL
> > Set objXML1 = Server.CreateObject("Microsoft.XMLDOM")
> > Set objXSL = getXMLDoc("default.xsl")
> > call objXML1.transformNodetoobject(objXSL, Response)
> >
> > I am tempted to uninstall the security update (Workaround 1) if I can.
> > However I would be willing to implement the wrapper you mentioned 
> > (workaround
> > 2). If it worked. I would do the coding. Every page unfortunately. Could 
> > help
> > me with some sample code for this. It would be appreciated.
> >
> > Workaround 3 I tried however, my web site works in three languages and 
> > when
> > I do the transform to an intermediate object document and then do
> > Response.Write   I then loose all special foreign characters somehow. If I
> > transform right to the response object the special characters in German 
> > and
> > Spanish show correctly   and works great.
> >
> > Workaround 4 is not an option for me.
> >
> > Again thanks for the help. I was waiting for something like this to happen
> > with all the automatic updates.
> >
> 
> Response.CodePage = 65001
> Response.CharSet = "UTF-8"
> Response.Write objXML1.transformNode(objXSL)
> 
> This code should work for all characters.
> 
> Does the above not work for you?
> Can you provide an example characters you are having trouble with?
> 
> -- 
> Anthony Jones - MVP ASP/ASP.NET
> 
> 

Hi Anthony,

Thanks for that. Changing the code page did it.  Now characters like ©  or 
the spanish Ñ show up correctly.    I had the Response.charset set to UTF-8 
already.

Now I just have to change all the pages.

Thanks

Luis Vargas