views:

905

answers:

1

It seems there is a bug in SQL Server Integration Services 2005 which, in certain circumstances, converts a zero length string into a single character string whose character happens to be an ansi null, ie. ascii character zero (Please note that this is very different from a sql null).

This happens to one of our data load processes so that address lines which should be empty get these characters in them.

We expose this data via web services and the data serialises ok. The nulls even get stripped by the standard XSL when the web service response is viewed via IE however when you view source you can see them:

Addr2="�"

But when you call this service from a .Net generated proxy you get an error:

"There is an error in XML document"

This is presumably because the null terminates the document and therefore invalidates it.

Though we can try our best to prevent these getting into the database, is there any way to prevent the proxy code from erroring when these values are in the response? We do not really want to add code to all our web methods to detect and remove these.

+1  A: 

I had a similar problem, although it happened in our own web service. To diagnose the problem I debugged the generated XmlSerializer DLL's. You can do that by adding

<system.diagnostics>
  <switches>
    <add name="XmlSerialization.Compilation" value="4"/>
  </switches>
</system.diagnostics>

See MSDN article for details.

We were able to fix the problem at the web service side.

Another solution may be found at this location.

Rine
Thanks for the config tip. That could well be useful. I'm not so sure about the solution in the other link because the issue is to do more with an ascii zero character rather than a null (if you appreciate the subtle difference)
Chris Simpson