code pages mess

Hi,
I have inherited a problem with code pages. When the server has a
different code page to the client the unrecognised characters are being
passed across as a question mark - ?.
I believe this is because SQL Server tries to translate it to the code
page it is using but can't find a match.
Is there a way to stop this attempted translation so that it just
passes it over as the character it is?
I'm not really up with different character sets and what is possible.
But the only reliable way to stop it is to make sure both client and
server are using the same code page.
Thank you.Hi
Displaying an unknown character as a question mark is usually a feature of
the client tools and not the server. If you check out the character value in
the database and on the client you will find they are the same.
John
"Feldaspar" wrote:

> Hi,
> I have inherited a problem with code pages. When the server has a
> different code page to the client the unrecognised characters are being
> passed across as a question mark - ?.
> I believe this is because SQL Server tries to translate it to the code
> page it is using but can't find a match.
> Is there a way to stop this attempted translation so that it just
> passes it over as the character it is?
> I'm not really up with different character sets and what is possible.
> But the only reliable way to stop it is to make sure both client and
> server are using the same code page.
> Thank you.
>|||No they are different,
It appears to be a bug with the OLEDB driver, see
http://support.microsoft.com/defaul...kb;en-us;234748
John Bell wrote:
[vbcol=seagreen]
> Hi
> Displaying an unknown character as a question mark is usually a feature of
> the client tools and not the server. If you check out the character value
in
> the database and on the client you will find they are the same.
> John
> "Feldaspar" wrote:
>|||Hi
The OLEDB driver is a client component! Have you checked whether you are
up-to-date with MDAC using the MDAC checker and load a more recent version i
f
inconsistent or old http://msdn.microsoft.com/data/ref/mdac/downloads/
John
"Feldaspar" wrote:

> No they are different,
> It appears to be a bug with the OLEDB driver, see
> http://support.microsoft.com/defaul...kb;en-us;234748
>
> John Bell wrote:
>
>|||Taken from
http://msdn.microsoft.com/library/d...ataencoding.asp
Disabling the AutoTranslate feature of the SQL Server ODBC driver to
insert data defined with a different code page from the server is not
supported. Also, even if AutoTranslate is disabled, it does not prevent
code page translation for SQL language events. The result is that if
the client and database code pages do not match, code page translation
will generally be applied to any non-Unicode character string sent to
or from the server. (For more information about AutoTranslate, see
Autotranslation of Character Data and PRB: SQL Server ODBC Driver
Converts Language Events to Unicode.
If possible, you should avoid this situation. The best choice for a
code page-specific server is to communicate only with clients using the
same code page. The second-best choice is to use another code page that
has an almost identical character set. For example, code page 1252
(Latin1) and code page 850 (Multilingual Latin1) can store an almost
identical set of characters, so most characters in these two code pages
can be converted from one code page to another without data loss.
If you must communicate with clients using different code pages, the
supported solution is to store your data in Unicode columns. If any of
these options is not feasible, the remaining alternative is to store
the data in binary columns using the binary, varbinary, or image data
types. Binary data, however, can only be sorted and compared in binary
order, making it less flexible than character data.
----
--
Our database is using text fields, not ntext (Unicode) so i guess we
have to look at changing things to unicode.|||Hi
If you are forcing unicode data into char/varchar columns then you could
have problems and it should be changed.
What you may want to find out is why you have inconsistentency in the way
the clients have been configured.
John
"Feldaspar" wrote:

> Taken from
> http://msdn.microsoft.com/library/d...ataencoding.asp
> Disabling the AutoTranslate feature of the SQL Server ODBC driver to
> insert data defined with a different code page from the server is not
> supported. Also, even if AutoTranslate is disabled, it does not prevent
> code page translation for SQL language events. The result is that if
> the client and database code pages do not match, code page translation
> will generally be applied to any non-Unicode character string sent to
> or from the server. (For more information about AutoTranslate, see
> Autotranslation of Character Data and PRB: SQL Server ODBC Driver
> Converts Language Events to Unicode.
> If possible, you should avoid this situation. The best choice for a
> code page-specific server is to communicate only with clients using the
> same code page. The second-best choice is to use another code page that
> has an almost identical character set. For example, code page 1252
> (Latin1) and code page 850 (Multilingual Latin1) can store an almost
> identical set of characters, so most characters in these two code pages
> can be converted from one code page to another without data loss.
> If you must communicate with clients using different code pages, the
> supported solution is to store your data in Unicode columns. If any of
> these options is not feasible, the remaining alternative is to store
> the data in binary columns using the binary, varbinary, or image data
> types. Binary data, however, can only be sorted and compared in binary
> order, making it less flexible than character data.
> ----
--
> Our database is using text fields, not ntext (Unicode) so i guess we
> have to look at changing things to unicode.
>