"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