If the SQL's default language (set up in the installation) is CJK, there is no problem to insert ANSI CJK string.

However, when the SQL default language is English (non-CJK), I can insert ANSI CJK string with the Query Analyzer,
but if I use DBLibrary to do so, the data becomes garbage.

(It looks conversion has been taken place. I guess SQL server (server-side) instead of the DBLibrary (client-side) doing the conversion with the default English collate. So isn't even if the symbol 'N' is NOT added, SQL always encodes non-unicode string to it target non-Unicode table?)

I've used DBSETLAPP(login, "Traditional Chinese") to set to the CJK session collate but it didn't help.

I tried all the combination of the 2 options ("Using international setting" and "Automatic ANSI to OEM conversion") in "Clinet Network Utility" but It still didn't help!


So is there any way to change the default session collate setting to my target collate with DBLIB in order to insert ANSI CJK string into SQL?

System Configuration:
SQL Server 2000 installed with English collate.
Create a table having columns of either VCHAR or CHAR inside a CJK-collate database.

Your kind help is appreciated!

=?Utf-8?B?bWFjIHNpbW9u?= (anonymous@discussions.microsoft.com) writes:
[quoted text, click to view]

The function to use would be DBSETLNATLANG, but that was maybe a typo of
yours.

In any case, I get the impression that DBSETLNATLANG, is just the
equivalent of SET LANGUAGE, which controls language of error message
and interpretation of date literals, but not character conversion.

Since my experience of CJK is thin, and even more thin when it comes to
non-Unicode, I can't play around with this myself. I know that with
ADO and ODBC you can get ANSI-to-ANSI conversions, but I did think that
could happen with DB-Library. Anyway, what are the regional settings
of the client that runs the DB-Lib app?

I hope you aware of that DB-Library is a dead API, as far as Microsoft
is concerned, that there has been no development for it for a long time.
Thus, migrating to a newer API can be worth considering.

--
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at