We are developing an add-on for GoldMine, however my problem is a
generic SQL Server problem. The situation is this; we have a database,
with collation set to SQL Latin. When we connect to database via
Goldmine, Enterprise Manager or Delphi (through ADO) we cannot see
Turkish characters. When I set SQL Server machine's "Language For
Non-Unicode Programs" setting to Turkish, GoldMine works fine, however
there is still problem in EM and Delphi.
Does anybody know how to solve this issue?(saygin@.gmail.com) writes:
> We are developing an add-on for GoldMine, however my problem is a
> generic SQL Server problem. The situation is this; we have a database,
> with collation set to SQL Latin. When we connect to database via
> Goldmine, Enterprise Manager or Delphi (through ADO) we cannot see
> Turkish characters. When I set SQL Server machine's "Language For
> Non-Unicode Programs" setting to Turkish, GoldMine works fine, however
> there is still problem in EM and Delphi.
> Does anybody know how to solve this issue?
What datatype does the columns have? varchar or nvarchar?
Exactly which collation are you using? There are a whole number of
collations with the name starting with "SQL_Latin".
Do all Turkish characters get mashed? Or only some? Does (lowercase C with
cedilla) work? If not, how do you see it in EM? How does the dotless
lowercase i get represented?
Which client API do you use in Delphi?
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Hi,
Exact collation is SQL_Latin1_General_CP1_CI_AS.
Not all characters are mashed, (c with credila) is ok, however
dotless i becomes y. (u with dots) are ok, however s (s with
credila) and g (g with ~ over it) becomes ? (question mark)|||And by the way, I use ADO to connect with Delphi.|||iSt (saygin@.gmail.com) writes:
> Exact collation is SQL_Latin1_General_CP1_CI_AS.
> Not all characters are mashed, (c with credila) is ok, however
> dotless i becomes y. (u with dots) are ok, however s (s with
> credila) and g (g with ~ over it) becomes ? (question mark)
Are you using varchar or nvarchar?
If you are using varchar you are fighting an uphill battle. The code
page SQL_Latin1_General_CP1_CI_AS is CP1252 which is not the best
code page for Turkish.
You should use a collation with code page 1254, for instance
SQL_Latin1_General_CP1254_CI_AS or any of the collations with
the name starting with Turkish.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Hi,
DB comes default with this collation. And if I offer to change, I can
be asked how GoldMine can show TR characters without problem.|||Columns are varchar by the way...|||iSt (saygin@.gmail.com) writes:
> DB comes default with this collation. And if I offer to change, I can
> be asked how GoldMine can show TR characters without problem.
I don't know what means of connection GoldMine uses. I have not heard of
the program before.
But when you connect through most APIs, they will perform a character
conversion to similar characters. The one API where this does not happen
is the old DB-Library.
By the way, if you got that collation installed by default, this means
that your operating system has US English as its default language. Had
the OS had Turkish as its default language, you would had been offered
Turkish_CI_AS as your default collation.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
No comments:
Post a Comment