The forum will be down for scheduled maintenance on Saturday, March 4 beginning at 10am EST. Actual downtime is unknown but may be several hours.

We migrated our DB from SA 9.02.3951 to SA Our last remaining problem to resolve is with SOAP request, with some charset conversion. With version 9, we don't have problem sending string value, char(100) with french characters (é, è, etc..) the procedure receive the correct value. With SA16, any string value with these chars are received as 1A1A (hex).

DB charset is cp1252, client making the SOAP request is IIS by an application developed in C#.

Any suggestion ?

asked 25 Aug '14, 15:07

lebpas's gravatar image

accept rate: 0%

0x1A is the ASCII/ANSI style [SUB] code point for charset translation errors.

It may be possible the data is currently just encoded that way due to an input translation error; ie. do check the binary on those column values to see if this is a problem on the input side.

About the only way I can see such an translation error occurring during the building of the SOAP XML response would be if your SOAP request is requesting a charset for which those 'code points' (symbols) are not available. Can you find out what your HTTP Content-Type: header is in your request?

A typical setting for that would be: Content-Type: text/xml; charset="utf-8"

You could even see this if you happen to be requesting the response be encoded as ISO-1 (which does not reflect typical C# usage since that is a Unicode environment) for the extensions to ISO-1 Microsoft added to CP1252 {See the symbols in the range 0x80-0x9f Wikipedia} but that doesn't match your description.


(26 Aug '14, 09:58) Nick Elson S...

Is this a new behaviour to just that build or did you also see this in earlier builds of V16? If not let us know which builds did you test with before you saw this.

(26 Aug '14, 10:12) Nick Elson S...
Replies hidden

In the header for the response I have this: Content-Type: text/xml; charset=windows-1252

And in the request we also have: Accept-Charset: windows-1252, UTF-8, *

We did not test other build with SA16, migrated directly from 9.02.3951.

We also tested with Fiddler, and see 'é' chars in the logs, so our guess is that SA is doing some kind of charset conversion and should not.

(26 Aug '14, 11:26) lebpas

We made some progress. It looks like SA is converting char twice. We send the utf-8 string 'Allé' ('Allé' in cp1252). The stored proc for the webservice receive 'Allé' (parameter). But when inserting the data in a table, wrong value is inserted, before the insert we have to csconvert the variable from cp1252 to utf-8, as if the webservice itself convert from utf-8 and then again on the insert statement.

(27 Aug '14, 09:51) lebpas
Replies hidden

A very wild guess: Does the following topic relate to your problem?

Character set conversion considerations

(27 Aug '14, 10:21) Volker Barth

Unfortunately, this does not apply to our situation.

(02 Sep '14, 14:59) lebpas
Comment Text Removed
showing 3 of 6 show all flat view

We found a working solution. Instead of using the procedure input parms directly, obtaining the value from http_variable('parm') does the trick for us.

permanent link

answered 02 Sep '14, 15:02

lebpas's gravatar image

accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 25 Aug '14, 15:07

question was seen: 1,090 times

last updated: 02 Sep '14, 15:02