Yazılım geliştirme günlüğü

--Bütün dilleri listeleyelim.
EXEC sp_helplanguage
--Sadece Türkçe dilinin bilgilerini görelim
EXEC sp_helplanguage turkish
--Doğrudan syslanguages tablosunu sorgulayalım.
SELECT * FROM sys.syslanguages WHERE alias='turkish'

sp_configure 'default language', 22--turkish yani
reconfigure with override--Aksi durumda SQL restart olduktan sonra aktifleşir

SELECT @@language --us_english döndürdü
--Bu oturumda geçici olarak dili değiştirelim.
SET LANGUAGE turkish
SELECT @@language--Türkçe döndürdü

--Tarih formatını day, month, year olarak düzenleyelim.
SET DATEFORMAT dmy
DECLARE @Tarih DATETIME
SET @Tarih = '31/12/2006'
SELECT @Tarih AS Tarih

EXEC sp_defaultlanguage 'Ayse', 'Turkish'

ALTER LOGIN Ayse WITH DEFAULT_LANGUAGE = Turkish

SELECT * FROM fn_helpcollations()

SELECT SERVERPROPERTY('collation')

CREATE DATABASE FrDatabase COLLATE French_CI_AI

--Sistemdeki databaselerin collation bilgilerini listeyelim
SELECT name, collation_name FROM sys.databases

CREATE TABLE [dbo].[OGRENCI](
	[AdSoyad] [char](10) COLLATE Turkish_CI_AS NULL
) ON [PRIMARY]

--Kayıt gelir
SELECT * FROM UYE WHERE UserNameTr='MCicekci' 

--Kayıt gelmez
SELECT * FROM UYE WHERE UserNameTr='MCICEKCI' 

--Kayıt gelir
SELECT * FROM UYE WHERE UserNameEng='MCicekci' 

--Kayıt gelir
SELECT * FROM UYE WHERE UserNameEng='MCICEKCI' 

--Eğer TR collation'da her iki kaydında gelinmesi isteniyorsa
-- COLLATE ifadesi kullanılır.
SELECT * FROM UYE
WHERE UserNameTr= 'MCIcekcI' COLLATE SQL_Latin1_General_CP1_CI_AS

ALTER TABLE  ALTER COLUMN  COLLATE 

SELECT * FROM UYE
WHERE UserNameTr=UserNameEng

44 Responses to “SQL Server’de Language ve Collation kavramı”

1. yoldaş erdoğan Says:
   Mart 21st, 2007 at 09:14

   Açıklayıcı bilgileriniz için teşekkürler.

   yoldas.cu.edu.tr

2. Berna Botali Says:
   Nisan 23rd, 2007 at 12:15

   Daha once tanımlanmış bir veritabanının collaction degerini nasıl değiştirebiliriz ?

   ALTER DATABASE benimDatabase COLLATE TURKISH_CI_AS

   ile yapamadım..

   Teşekurler.

3. Ahmet Kaymaz Says:
   Nisan 24th, 2007 at 08:24

   Merhaba,

   ALTER DATABASE benimDatabase COLLATE TURKISH_CI_AS ifadesinin başarılı olabilmesi için veritabanının “single user mode”ta çalışıyor olması lazım. Yani bu işlemi yapmadan önce, “benimDatabase” isimli database üzerinde herhangi bir connection’ın açık olmadığından emin olmanız gerekir. Bunun için sp_who ifadesini kullanarak gelen sonuç içerisindeki dbname kolonunda bu database üzerinde herhangi bir connection olup olmadığını kontrol edebilirsiniz. Eğer varsa o işlemin spid değerini alıp kill ifadesiyle o processi iptal edebilirsiniz.
   Veya doğrudan bu işlemi, veritabanını anlık olarak single moda çekerek te T-SQL ile gerçekleştirebilirsiniz. ALTER DATABASE benimDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE benimDatabase COLLATE TURKISH_CI_AS
ALTER DATABASE benimDatabase SET MULTI_USER

   Buna ek olarak bu işlemin, bütün index ve foreign key’lerinizi drop ve ardından rebuild ettiğini, nText, nvarchar gibi kolonların uyumluluğunun test edildiğini, yalnızca default collation olarak set edilmiş kolonların etkilendiğini, özellikle büyük veritabanların işlemin uzun sürdüğünü de gözönünde tutmanız faydanıza olacaktır.

4. Tunç Askin Says:
   Nisan 27th, 2007 at 09:17

   merhaba

   databese dilim TURKISH_CI_AS
   ama bazı table lerin içindeki COLLATION ler SQL_Latin1_General_CP1_CI_AS yazıyor ben bunları degıstırmek ıcın tek tek desing table ya girip yapıyorum
   bunun daha bır kolay yolu varmıdır
   tesekurler

5. Ahmet Kaymaz Says:
   Nisan 29th, 2007 at 15:54

   Merhaba Tunç bey, bu işlem için farklı alternatifler kullanabilirsiniz.Birinci yöntem olarak aşağıdaki adımları takip edebilirsiniz;

   1. Database’deki tüm nesnelerin SQL Script’i generate edilir.
   2. Script deyimlerinin içindeki COLLATE ifadeleri silinir
   3. Olmasını istediğimiz Collation tipinde yeni bir database oluşturulur.
   4. Oluşturulmuş SQL Script’in, “foreign key tanımlamaları” bölümü hariç bu database üzerinde çalıştırılarak tüm nesneler yaratılır.
   5. Data Import/Export aracılığıyla eski databaseteki veriler yenisine aktarılır
   6. “foreign key tanımlamaları” çalıştırılır.

   İkinci yöntem olarak katalog şemalar kullanılarak her tablodaki kolon için ALTER TABLE . . . ifadesi oluşturulur. Bu ifadede, düzenlenecek kolonun tablo, veri tipi, uzunluk, null kabul edip etmediği gibi bilgiler girilmelidir. Bu yüzden INFORMATION_SCHEMA.COLUMNS şeması kullanılır. Aşağıdaki T-SQL scripti bütün tablolardaki COLLATION_NAME değeri “SQL_Latin1_General_CP1_CI_AS” olan tüm kolonlar için çalıştırılacak ALTER TABLE ifadesini oluşurur.SELECT 'ALTER TABLE ' + TABLE_NAME +
' ALTER COLUMN ' + COLUMN_NAME + ' ' + DATA_TYPE +
CASE WHEN CHARACTER_MAXIMUM_LENGTH = -1 THEN '(max)'
WHEN DATA_TYPE in ('text','ntext') THEN ''
WHEN CHARACTER_MAXIMUM_LENGTH IS NOT NULL
THEN '('+(CONVERT(VARCHAR,CHARACTER_MAXIMUM_LENGTH)+')' )
ELSE
ISNULL(CONVERT(VARCHAR,CHARACTER_MAXIMUM_LENGTH),' ')
END
+' COLLATE TURKISH_CI_AS ' +
CASE IS_NULLABLE WHEN 'YES' THEN 'NULL' WHEN 'No' THEN 'NOT NULL'
END
FROM INFORMATION_SCHEMA.COLUMNS
WHERE DATA_TYPE IN ('varchar' ,'char','nvarchar','nchar','text','ntext')
AND COLLATION_NAME = 'SQL_Latin1_General_CP1_CI_AS' Bu “ALTER TABLE . . .” ifadeleri single modda çalıştırıldığı zaman ilgili kolonların collation değeri “TURKISH_CI_AS” olarak set edilmiş olur.

6. Yener Arslan Says:
   Haziran 18th, 2007 at 10:43

   Teşekkürler.

7. Murat Çim Says:
   Eylül 21st, 2007 at 02:19

   Verdiğiniz bilgiler çok faydalı.
   Teşekkürler.

8. Yoldaş Yılmaz Says:
   Eylül 23rd, 2007 at 03:01

   MÜKEMMEL, sade anlatımınız ve doyurucu bilgilerinizden dolayı teşekkür ederim.
   Aradığım çoğu sorunuma, tek bir çözüm dökümanı sunmuşsunuz. Başarılı çalışmalarınızın artarak devam etmesi dileklerimle…

9. Umit Dorduncu Says:
   Ekim 5th, 2007 at 16:05

   Merhaba,
   SQL 2005 uzerindeki TURKISH_CI_AS olan bir database imde Rusça ve Yunanca karakterleri de gormek istiyorum, bunun icin Collation değerini SQL_Latin1_General_CI_AS yapmak istiyorum ama server uzerinden bu değişikliği yapamiyorum.

   bu hatayi aliyorum :

   TITLE: Microsoft SQL Server Management Studio
   ——————————

   Alter failed for Database ‘airties’. (Microsoft.SqlServer.Smo)

   For help, click: http://go.microsoft.com/fwlink?

   ——————————
   ADDITIONAL INFORMATION:

   An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

   ——————————

   The database could not be exclusively locked to perform the operation.
   ALTER DATABASE failed. The default collation of database ‘airties’ cannot be set to Latin1_General_CS_AI. (Microsoft SQL Server, Error: 5030)

   For help, click: http://go.microsoft.com/fwlink?
   ———
   Yardimci olabilir misiniz?

   Tesekkurler..

10. Ahmet Kaymaz Says:
    Ekim 5th, 2007 at 20:05

    Ümit bey,

    database’in collation değerini nasıl değiştirmeye çalıştığınızı da yazmış olsaydınız sonuca daha hızlı varmış olurduk. Bunu “ALTER DATABASE” ifadesiyle yapmaya çalışıyorsunuz diye tahmin ediyorum. SQL Server’da bir database’in collation bilgisini değiştirmek için o database’i öncelikle single moda getirmeniz gerekmektedir. Aşağıdaki kodu master veritabanına geçip olduğu gibi kullanırsanız sorununuz çözülür diye düşünüyorum.ALTER DATABASE airties SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE airties COLLATE SQL_Latin1_General_CP1_CI_AS
ALTER DATABASE airties SET MULTI_USER

    Ayrıca “SQL_Latin1_General_CI_AS” ismiyle “SQL_Latin1_General_CP1_CI_AS” serisini kasdediyorsunuz sanırım.

11. Volkan GÖKBAYRAK Says:
    Ekim 18th, 2007 at 15:08

    Merhaba,
    Çok teşekkürler Ahmet bey makaleniz için,
    Bir sorun olucak zaman ayırırsanız,
    Sql Serverımda “Server Collation” “SQL_Latin1_General_CP1254_CS_AS” olarak kurulu.
    Yeni bir programa geçiş aşamasındayız ve bu program “Turkish_CI_AS” ile çalıştığını bildirdiler.Şu an kullanılan muhasebe programı ise
    Üzerinde çalışan muhasebe uygulamasına destek veren ekip “Turkish 1254 case sensitive” olarak çalışması gerektiğini söylüyorlar.
    Bu noktada sorum şu olucak SQL_Latin1_General_CP1254_CS_AS,
    “Turkish_CI_AS” ile “Turkish 1254 case sensitive” kapsamaktamıdır.Bu 2 muhasebe programını aynı serverda mevuct haliyle sorunsuz çalıştırabilirmiyim.
    Teşekkür ederim

12. Ahmet Kaymaz Says:
    Ekim 19th, 2007 at 15:41

    Merhaba Volkan bey,

    Collation değeri birbirinden farklı iki database aynı server üzerinde çalışabilir hatta farklı collation değerine sahip iki farklı tablo aynı database içinde de çalışabilir. Ama bu tablolar arasında JOIN işlemi yapmaya çalıştığınızda ya da aktarım gibi işlemlerde bulunduğunuzda Cannot resolve collation conflict for equal to operation. şeklinde collation hatası alırsınız. Ama anladığım kadarıyla bu iki database’in birbiriyle ilişkisi olmayacak bu durumda aynı SQL Server Instance üzerinde farklı collation değerlerine sahip olmaları sorun oluşturmayacaktır.
    Yeni bir database oluşturduğunuzda varsayılan olarak database’in collation değeri “(Server default)” seçimlidir. Ama bunu değiştirip database’e özgü collation tanımlayabilirsiniz. Aynı şekilde bir tablodaki char tipindeki kolonları oluşturduğunuzda varsayılan olarak içinde bulunduğu database’in collation değerini alır fakat bunu kabul etmeyi o kolon için farklı bir collation tanımlayabilirsiniz.

13. Volkan Gökbayrak Says:
    Ekim 22nd, 2007 at 13:34

    Teşekkür Ederim.
    Sayğılar

14. serdar Says:
    Ekim 23rd, 2007 at 23:30

    gercekten çok güzel bir döküman ellerinize sağlık

15. Yunus Kellekule Says:
    Kasım 14th, 2007 at 12:33

    Merhaba Ahmet Bey,

    SqlServer ile turkce karakterler ile ilgili bir problemim var. Internette cozum ararken sitenize rastladim. Umarim siz bir cozum sunabilirsiniz.

    Yakin zamanda bir Turk sirketi ile calisacagimiz icin, veritabanini ayarlamaya calisiyorum. Veritabaninda herhangi bir tablonun, kolomunu (ing. Column) Turkce karakterlere uyarmam gerek.

    Uyguladigim query sirasiyla:
    1. alter table PARAMETER alter column PARAMETERVALUE nvarchar(1500) COLLATE Turkish_CI_AS;

    2. update PARAMETER set PARAMETERVALUE = ‘ç;ı;ğ;ö;ş;ü’ where PARAMETERNAME = ’specialtoken’

    3. select PARAMETERVALUE from PARAMETER where PARAMETERNAME = ’specialtoken’

    Son querynin sonucu: ç;i;g;ö;s;ü

    Yani Turkce karakterli degil.

    Daha sonra:
    ALTER DATABASE Demo SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    ALTER DATABASE Demo COLLATE Turkish_CI_AS
    ALTER DATABASE Demo SET MULTI_USER

    denedigim zaman:
    Server: Msg 5075, Level 16, State 1, Line 1
    The object ‘SEARCHFIELD’ is dependent on database collation.
    Server: Msg 5075, Level 16, State 1, Line 1
    The object ‘VALIDATOR’ is dependent on database collation.

    seklinde uyarilar cikiyor.

    Simdiden tesekkurler,

    Yunus Kellekule
    Icorp (Hollanda)

16. Ahmet Kaymaz Says:
    Kasım 14th, 2007 at 15:46

    Merhaba Yunus bey,

    Aslında normal şartlar altında Türkçe karakterleri doğru yazıyor ve okuyor olmanız gerekiyor. Fakar işlemi daha garantilemek için Windows Collation yerine SQL Collation kullanmak ve kodlarınızı unicode standarta (değerlerin başına “N” harfini eklemek) uygun olarak işlemek daha iyi bir çözüm olabilir. Yani şu işlemi yapmanız mümkün mü.
    alter table PARAMETER alter column PARAMETERVALUE nvarchar(1500) COLLATE Turkish_CI_AS;
update PARAMETER set PARAMETERVALUE = N'ç;ı;ğ;ö;ş;ü' where PARAMETERNAME = 'specialtoken'
select PARAMETERVALUE from PARAMETER where PARAMETERNAME = 'specialtoken' Eğer bu kod başarılı olmazsa SQL Collation türünü deneyebilirsiniz. Hem böylece Code Page de değiştirilmiş olur.
alter table PARAMETER alter column PARAMETERVALUE nvarchar(1500) COLLATE SQL_Latin1_General_CP1254_CI_AS;

    Aldığınız hata, “schema-bound object ” schemayı yüklemiş nesnelerin, bulundukları database’in collation değerine bağlı olmasından kaynaklanmaktadır. Schema-bound objeleri şunlardır;
    SCHEMABINDING ifadesiyle oluşturulmuş User-defined function ve View (Oracle’daki materialised view)
    Computed column
    CHECK constraint

    Veritabanınızda bu nesneler olduğu sürece veritabanını collation değerini değiştiremezsiniz. Büyük ihtimalle veritabanınızda WITH ENCRYPTION veya WITH SCHEMABINDING ile oluşturulmuş view veya functionlar vardır veya bahsi geçen kolonlar üzerinde Check Constraint’ler oluşturulmuştur. Örneğin aşağıdaki queryi çalıştırıp bu viewi yarattıktan sonra vwGetMusteri nesnesi MUSTERI tablosu na referans verdiği yani doğrudan onu gösterdiği için MUSTERI tablosu üzerinde değişiklik yapamazsınız “ALTER TABLE MUSTERI” ifadesi hata verecektir. CREATE VIEW vwGetMusteri With SCHEMABINDING
As
SELECT
AdSoyad, Unvan FROM DBO.MUSTERI

    Bu arada şunu söylemekte fayda vardır. Bir database’in Collation değerini değiştirmeniz içerde var olan nesnelerin collation değerini değiştirmez. Yani nesneler için ReCollate işlemi gerçekleşmez. Bu sorunlara karşılık size tavsiyem istediğiniz collation türünde yeni bir database yaratmak ve önceki database içindeki tüm nesnelerin SQL Script’ini oluşturup script içerisindeki collation bilgilerini yok edip scripti yeni database’de çalıştırmanız ardından da DTS ile dataları yeni veritabanına taşımanızdır.

17. ihsan erbil Says:
    Kasım 15th, 2007 at 11:57

    İyi Günler,
    Makaleniz oldukça güzel olmuş, fakat asıl bende takdir hisleri uynadıran; soruların hiçbirini es geçmeden cevaplamış olmanız. Bundan cesaret alarak bir soru da ben sormak istiyorum.
    Geçmişte DOS ortamı için tasarlanmış bir program ile oluşturulmuş veritabanına sahibim.Dolayısıyla veritabanında hiç türkçe karakter kullanılmamış. Bu veri tabanını sqlserver ortamına aktardım.Şimdi ben bir web programı yazıyorum ve benim kullanıcım normal olarak türkçe karakter kullanarak ta aradığını bulmak istiyor. Mesela “türkçe” yazıp “TURKCE” içeren veriler çekebilmem için; database’in Collate özelliğinden faydalanmam mümkün mü?

18. Yunus Kellekule Says:
    Kasım 15th, 2007 at 14:17

    Ahmet Bey,
    Bilgilendirdiginiz icin tesekkurler.
    Unicode standardi (N) ile turkce karakterleri tabloya katabilidim.
    En son tavsiyeniz, bence en uygun olani: Trukce karakterli yeni bir veritabani olusturmak.

    Tekrar tesekkurler,
    Yunus Kellekule

19. Ahmet Kaymaz Says:
    Kasım 15th, 2007 at 16:53

    İhsan bey,

    buradaki amacımız birlikte birşeyler öğrenmek olunca hiçbir ayrıntıyı hiçbir soruyu gözden kaçırmamak gekir diye düşünüyorum.

    Yapmak istediğinizi collation tabanlı bir sorgulamayla çözebilirsiniz. Tablonuzun C1 isimli kolonunda türkçe, TÜRKÇE, turkce, TURKCE,İŞİÇÖĞÜ,ISICOGU kayıtlarının bulunduğunu düşünelim. Sorgulama esnasında collate sözcüğüyle Türkçe karakterlerini desteklemeyen bir collation kullanırsanız aynı değerleri getirebilirsiniz. Örneğin şuanda aklıma Fransızca collation geldi. Aşağıdaki sorgulama tüm “türkçe” kayıtlarını getirir.SELECT * FROM TB
WHERE C1 collate French_CI_AI='Türkçe' Aynı şekilde eski kayıtlara uygun da arama yapılabilir. SELECT * FROM TB
WHERE C1 collate French_CI_AI='TURKCE'
    Aynı mantıkla aşağıdaki satır da “İŞİÇÖĞÜ” ve “ISICOGU” kayıtlarını getirir. SELECT * FROM TB
WHERE C1 collate French_CI_AI='İŞİÇÖĞÜ'
    
    Fakat bu işi bu şekilde collate ile yapmak hem performans açısından hem de usul açısından doğru olmaz kanısındayım. Bunun yerine bir REPLACE fonksiyonu kullanarak türkçe karakter dönüşümü yapmanız bir SQL Server geliştiricisine yakışır daha doğru bir davranış olacaktır.

20. Yasin Özbey Says:
    Aralık 4th, 2007 at 09:51

    Merhaba Ahmet bey
    Makaleleriniz çok faydalı teşekkürler.Benim sormak istediğim karakter seti değiştireceğimiz kolonda index veya anahtar varsa alter column hata veriyor.internette yaptığım araştırmada index veya anahtarları silip yeniden yaptıklarını gördüm sizce bu şekilde kayıt olan bi tablonun yapısını bozarmıyım veya yavaşlatırmıyım
    Teşekkürler

21. Ahmet Kaymaz Says:
    Aralık 5th, 2007 at 15:07

    Yasin bey,

    üzerinde index bulunan kolona ait collation değerini değitirmek istediğinizde büyük ihtimalle The index ‘‘ is dependent on column ‘‘ şeklinde hatası alıyorsunuzdur. Bunun için indexlerini kaldırıp yeniden oluşturmanız gerekiyor. Size tavsiyem, Generate SQL Script bölümünden bu tabloya tüm indexlere ait SQL Script’i çıkarmanız ve collation değişiminden sonra tekrar çalıştırmanızdır.

22. Erdal Sert Says:
    Ocak 14th, 2008 at 23:00

    Ahmet Bey,

    Collation’ı SQL_Latin1_General_CP1_CI_AS olarak set edilmiş bir sqlserver 2005 ve üzerinde aynı collation’da database’ler var.

    Bu databaselerde varchar olarak tutulan sahalardaki Türkçe karakterlerde sorunlar var.
    İ ler Y
    Ş ler ?
    şeklinde görülüyor. bu database’lere yazdığımız uygulamalarda da, dataları bu şekilde bozuk alıyoruz.
    Acaba bu karakterleri düzeltmenin bir yolu varmıdır ?
    Bu konuda öneriniz olur mu ?

23. Ahmet Kaymaz Says:
    Ocak 15th, 2008 at 09:18

    Erdal bey,

    İlk bakışta sorunun Collation tipinden kaynaklandığını söyleyebiliriz ancak bu durumda SQL_Latin1_General_CP1_CI_AS için “İ” lerin “Y” olarak değil “I” olarak yazılıyor olması lazım. Şu şekilde bir deneme yapmanızı tavsiye ederim. T1 isminde bir tablo oluşturalım bu tabloya varchar türünde C1 ve C2 kolonlarını ekleyelim. C1′in collation tipini SQL_Latin1_General_CP1_CI_AS, C2′nin collation tipini, Turkish_CI_AS olarak set edelim. Ardından şu cümleyi çalıştıralım.
    INSERT T1 VALUES('İÇÖĞÜŞ','İÇÖĞÜŞ')
SELECT * FROM T1 Bu querynin sonucunda veya doğrudan Management Studio’da tabloya baktığınızda “İÇÖĞÜŞ” değerini “IÇÖGÜS” olarak görüyorsanız bu sorunun collationdan kaynaklandığını ve bunu ancak collation tipini değiştirerek çözebileceğinizi söyleyebiliriz. Bu durumda aşağıdaki gibi bir sorgulama Insert ettiğimiz kaydı getirir.SELECT * FROM T1 WHERE C1='İÇÖĞÜŞ' Fakat aşağıdaki sorgulamayı denediğimizde hiçbir kaydın gelmiyor olması lazım. SELECT * FROM T1
WHERE C1='İÇÖĞÜŞ' COLLATE Turkish_CI_AS
    
    Eğer queryleirn sonuçları bu şekilde olmuyorsa, veriler tabloda doğru görünüyorsa sadece client uygulamanızda yanlış görünüyorsa uygulamanızın lokalizasyon değerlerini değiştirmeniz gerekir.

24. Erdal Sert Says:
    Ocak 16th, 2008 at 11:19

    Tekrar Merhaba,
    
CREATE TABLE Z1(T1 VARCHAR(50) COLLATE SQL_Latin1_General_CP1_CI_AS,
T2 VARCHAR(50) COLLATE Turkish_CI_AI)
go
INSERT Z1 VALUES('İÇÖĞÜŞ','İÇÖĞÜŞ')
SELECT * FROM Z1

    şöyle bir tablo yarattıp dediğiniz gibi insert yaptım.
    Select query’lerin sonuçlarıda şöyle…

    SELECT * FROM Z1 WHERE T1=’İÇÖĞÜŞ’

    T1 T2
    ——————– ——————
    IÇÖGÜS IÇÖGÜS

    (1 row(s) affected)

    ** ve ,

    SELECT * FROM Z1
    WHERE T1=’İÇÖĞÜŞ’ COLLATE Turkish_CI_AS
    T1 T2
    —————- —————————-
    IÇÖGÜS IÇÖGÜS

    (1 row(s) affected)

    Bu durumda şöyle bir deneme daha yaptım.
    C# ile bağlantıda sqlclient class’nı kullanırsam bu Türkçe karekterler bozuk geliyor, ilk yazdığım gibi İ ler Y vb..

    Fakat sqlclient yerine OleDB seçersem ve connection string’de “auto translate=false” paremtresini kullanrsam Türkçe’ler düzgün geliyor. Fakat bu seferde Insert cümlelerindeki Türkçe karakterleri değiştirip yazıyor.
    İ leri I , Ş leri S ve Ğ leride G olarak insert ediyor.

    Yani tam sorun oldu bu iş.
    SqlClient kullansam Select’de sorun var, OleDB kullansam Insert’de sorun var.

    Bir öneriniz olursa çok sevinirim…..

25. Ahmet Kaymaz Says:
    Ocak 16th, 2008 at 17:40

    Erdal bey,

    normal şartlar altında veritabanınızdaki collation değerini Turkish_CI_AS olarak set ettiğinizde ve web tarafında da utf-8′i referans aldığınızda Türkçe karakter sorununuzun kalmaması gerekir. Eğer hala devam ediyorsa SQL Server ve Framework’ü yeniden kurmanızı ve sunucudaki yerel ayarlarını kontrol etmenizi tavsiye ederim.

26. Erdal Sert Says:
    Ocak 16th, 2008 at 20:46

    Ahmet bey,

    pratikde Turkish_CI_AS ile Turkish_CI_AI arasında fark gördünüzmü ?

27. Ahmet Kaymaz Says:
    Ocak 17th, 2008 at 08:48

    Evet arasındaki aksan, şive dolayısıyla pratikte fark bulunmaktadır.

    Bu işin özeti şudur; birçok programcı için sorun oluşturan SQL Server’daki bu Türkçe karakter sorunu, Türkçe karakterlerinin bulunduğu character set’inin kullanılmasıyla çözülür. Bilindiği gibi Türkçe karakterleri, 16 gruptan oluşan Avrupa dil karakter setinin 9. grubu olarak ISO tarafından standart hale getirilerek ISO 8859-9 koduyla temsil edilmektedir. Bu karakter setleri referans alınarak IBM ve Microsoft Windows işletim sistemi tarafından bu karakterlerin tanınması, print edilebilmesi için Codepage denilen karakter setleri oluşturuldu. Microsoft’un oluşturduğu set, ANSI codepage olarak tanımlanır ve 1250-1258 arasındaki sayılarla temsil edilir. Örneğin 1254, Türkçe, 1256, Arapça dil karakter setini bildirir.
    SQL tarafında Türkçe karakterlerini desteklemek için Codepage 1254′in bulunduğu şu collationlar kullanılabilir;
    Turkish_BIN
    Turkish_CI_AI
    Turkish_CI_AS
    Turkish_CS_AI
    Turkish_CS_AS
    SQL_Latin1_General_Cp1254_CS_AS
    SQL_Latin1_General_Cp1254_CI_AS

    Collation yapısını, SQL Server’daki karakter karşılaştırma yöntemi olarak yorumlamalıyız. Bu collationların farkı, büyük küçük harf duyarlılığının olması ve aksan farklılıklarına karşı hassasiyeti desteklemesidir. Verdiğiniz iki collation arasındaki fark, aksana göre büyük küçük harf duyarlılığıdır. Aksan veya şive dediğimiz şey, çoğu zaman bölge ve şehir farklılığı sonucu kelimelere yapılmış vurgular olarak ortaya çıkar. Örneğin Karadeniz bölgesindeki “cideyrum” bir aksan farklılığıdır. “À Á Â Ã Ä Å” harfleri, “A” harfinin aksan farklılıkları sonucu ortaya çıkmıştır. Bu yüzden aksan yapısına göre “Kağıt” ile “Kâğıt” ifadeleri aynı değildir.

    Turkish_CI_AI ile Turkish_CI_AS arasındaki fark, aksan farklılıklarına karşı hassas olup olmayacaklarıdır. Bu farkı anlamak içina aşağıdaki örneği bu collation türlerine sahip iki farklı database’de çalıştıralım.DECLARE @Harf1 char(1)
DECLARE @Harf2 char(1)
set @Harf1 ='â'
set @Harf2 ='a'

    if @Harf1 = @Harf2
print 'a ile â aynı kabul edilir.'
else
print 'a ile â aynı kabul edilmez.'

    Bu query’i, Turkish_CI_AI türündeki bir database’de çalıştırırsanız a ile â aynı kabul edilir. mesajı, Turkish_CI_AS türündeki bir database’de çalıştırırsanız a ile â aynı kabul edilmez. mesajı döner. Eğer collation tipini Turkish_BIN yaparsak, bu durumda binary olarak karşılaştırma yapılacak ve “A” ile “a” aynı muameleyi görmeyecektir.

    Artık bu bilgiler ışığında kendi ihtiyacınıza en uygun collation değerini seçmelisiniz. Öncelikle database tarafındaki karakter sorununu halletmeniz gerekiyor. Client uygulama tarafında, sunucu yerel ayarları veya .NET’teki Culture nesnesiyle bu iş çözülür.

28. Erdal Sert Says:
    Ocak 18th, 2008 at 10:43

    Yardım ve önerileriniz için teşekkür ederim.

    İyi çalışmalar…

29. candan ildeniz Says:
    Şubat 5th, 2008 at 15:16

    Merhaba Ahmet bey,

    Bir SQL server 2000′in code page’i Cyrillic_General_CI_AS, database’lerde de aynı ama tablolarda hala Cyrillic karakterleri “?” işareti vb alakasız şekillerde görüntüleyebiliyorum. Aşağıdaki collationları denedim ama başarılı olamadım. Problem ne olabilir ?

    104 Cyrillic_General_BIN (or Ukrainian_BIN, Macedonian_BIN)
    105 SQL_Latin1_General_Cp1251_CS_AS
    106 SQL_Latin1_General_Cp1251_CI_AS
    107 SQL_Ukrainian_Cp1251_CS_AS
    108 SQL_Ukrainian_Cp1251_CI_AS

    teşekkürler.

30. Ahmet Kaymaz Says:
    Şubat 5th, 2008 at 20:38

    Merhaba,

    Cyrillic karakterleriyle ilgili sizin de listelediğiniz gibi birçok collation tanımlaması var. Bu da sanırım çok sayıda dilin bu alfabeleri kullanmasından kaynaklanıyor. Örnek olarak rusçadaki ????? harflerini kullanalım. Öncelikle database collation ne olursa olsun bir kolona her türlü karakterin tutulmasını istiyorsak o kolonu unicode olarak tanımlamalıyız yani ya nchar ya da nvarchar kullanmalıyız. Ve bu kolonlara kayıt eklerken, kolonda arama ve güncelleme yaparken mutlaka değerin önüne onun unicode olduğunu ifade eden “N” önekini kullanmalıyız. Bu durumda nchar veya nvarchar kolonda Cyrillic karakterlerini de Arapça karakterlerini de rahatlıkla tutabiliriz. Ama char veya nchar gibi non-unicode kolonlara kaydedeceğimiz veri için o kolonun Collation tanımlamasının ne olduğunu önemlidir. Örneğin Turkish_CI_AS olarak set edilmiş bir char veya nchar kolonuna başına “N” eklesek bile hiçbir şekilde Cyrillic veya Arapça alfabesinden bir değer girilemez, ???? olarak görülür. Eğer bu kolonlara Cyrillic karakterlerini de yazdırmak istiyorsak o zaman Cyrillic tabanlı bir collation seçmeniz yeterli olacaktır. Sizin vermiş ilk bakışta gözüme çarpan Cyrillic_General_CI_AI tipi yeterli gelecektir. Bu durumda da yine SQL Server’e veri gönderirken mutlaka başında “N” ifadesi olmalıdır.

    Buna rağmen Cyrillic karakterlerini SQL Server’da doğru barındıramıyorsanız tablonun sql scriptini incelemek lazım. Sözkonusu scripti ve örnek bir insert, update cümlesi yazabilirseniz daha iyi yardımcı olabilirim.

31. FZK Says:
    Şubat 28th, 2008 at 21:09

    Merhaba;

    Uzun süredir Türkçe Collation’ı olan bir SQL 2000 veritabanı kullanıyordum (default server collationı latin idi). Bugün içindeki tabloları collation’ı Latin olan bir SQL 2005 veritabanına sorunsuz aktardım. Yani Türkçe karakterler doğru olarak gitti. Ama mesela yeni kayıt girişi veya güncellemesi yaptığımda başına “N” koymassam eğer Türkçe karakterler (ş, ı, ğ) Latin’e çevriliyor. ‘N kullanmadan bu sorunu halledemem mi acaba?

32. Ahmet Kaymaz Says:
    Şubat 29th, 2008 at 10:12

    Merhaba,

    Aktardığınız tablo doğal olarak hedef database’in collation değerini alacaktır. Latin derken neyi kastettiğinizi anlamadım. Latin1_General_CI_AS seçeneğini mi kastediyorsunuz. Database’i olduğu gibi değil belli tabloları import/export yaptığınız için bu tabloların collation değeri değişir. Bunu engellemek yani tabloların collation değerlerini koruması için önceki database üzerinde bu tabloları SQL Script’ini oluşturup yeni serverde çalıştırırsınız ardından import/export aracıyla datalar taşınır.

    Yeni sunucuda yeni kayıtları girdiğiniz neden Türkçe karakterlerin düzgün yazılmadığı ya da “N” önekini kullanma zorunluluğu tablonuzun yapısına bağlı bir durum. Önceki sunucudaki tabloya ait SQL Script veya yeni sunucudaki tabloya ait SQL Script’i gönderebilirseniz daha net görürüz.

33. ali haydar eroğlu Says:
    Mayıs 28th, 2008 at 15:19

    Ahmet Bey verdiğiniz bilgilerle takılmış olduğum bir işte büyük yok aldığımı düşünüyorum. Emeğiniz ve paylaştığınız bilgi için çok teşekkürler.

    sitenize google da collation ı serch ederken ulaştım. sql2005 de mevcut bir database in collation ı SQL_Latin1_General_CP1251_CI_AS, bense bunu SQL_Latin1_General_CP1_CI_AS e çevirmeye çalışıyorum. bunu için yukarıda verdiğiniz sorguyu çalıştırdım. ALTER DATABASE benimDatabase SET (SINGLE_USER WITH ROLLBACK IMMEDIATE
    ALTER DATABASE benimDatabase COLLATE TURKISH_CI_AS
    ALTER DATABASE benimDatabase SET MULTI_USER)
    ancak aşağıdaki hata mesajlarını aldım.
    Msg 5075, Level 16, State 1, Line 1
    The object ‘TBLNPMRELDET_CHK1′ is dependent on database collation.
    Msg 5075, Level 16, State 1, Line 1
    The object ‘NETPROCESSID’ is dependent on database collation.
    Msg 5075, Level 16, State 1, Line 1
    The object ‘CC_PAYDA_1′ is dependent on database collation.
    Msg 5075, Level 16, State 1, Line 1
    The object ‘CC_PAYDA2′ is dependent on database collation.
    Msg 5072, Level 16, State 1, Line 1
    ALTER DATABASE failed. The default collation of database ‘TENIS06′ cannot be set to SQL_Latin1_General_CP1_CI_AS.

    çözümün ne olduğunu yine yukarııda yazmışsınız.
    (Generate SQL Script bölümünden bu tabloya tüm indexlere ait SQL Script’i çıkarmanız ve collation değişiminden sonra tekrar çalıştırmanızdır.)

    ancak sql konusunda yeni olduğum için bu cümle benim için fazla birşey ifade etmiyor. sanırım bunun anlamını öğrendiğimde sorunumuda çözmüş olacağım.

    iyi çalışmalar, teşekkürler.

34. ali haydar eroğlu Says:
    Mayıs 28th, 2008 at 15:43

    indexlerin kaldırılması nedemektir, nasıl yapılır? collation dan sonra bu table ların indexi nasıl oluşturulur?

35. Ahmet Kaymaz Says:
    Mayıs 29th, 2008 at 22:54

    Haydar Bey,

    eğer bu hatayı “ALTER DATABASE” ifadesinde alıyorsanız sorun indexlerden değil veri tabanında bulunan constraint’lerden kaynaklanıyordur. Bu yüzden öncelikle constraint’leri önce kaldırıp collation bilgisini düzenledikten sonra oluşturmalısınız. Aynı durum tablolar üzerindeki indexler için de geçerlidir.

    Size tavsiyem öncelikle database’in tüm SQL Script’ini oluşturmanız ardından bu script’teki collation bilgilerini isteğinize göre düzeltmeniz ve bu script’i kullanarak yeni bir database oluşturmanızdır. Ardından eski database’den yeni database’e verileri import/export yöntemiyle aktarmanızdır.

    Bir database’in SQL Script’ini çıkarmak için Management Studio içerisinde Database’i sağ tıklayıp Tasks bölümünden “Generate Scripts” menüsünü kullanabilirsiniz. Bu bölüm bir wizard olduğu için sizi yönlendirecektir.

36. Orhan kızıltee Says:
    Haziran 3rd, 2008 at 15:12

    Ahmet Bey, makaleniz için çok teşekkür ederim;

    yazmakta olduğum C# uygulamasının farklı sunucularda çalışablimesini sağlamak istiyorum, bunun için sunucunun Tarih formatını öğrenip , o formata dönüştürerek sorgularımı oluşturmak istiyorum.

    sunucunun veya bir veritabanının tarih formatına ait bilgiyi nasıl alabilirim.

    denediğm sunucuda

    SELECT @@LANGUAGE — > us_english dönüyor fakat,
    ” select collation_name from sys.databases where name = N’VeriTabani’ ”
    sorgumun sonucunda “Turkish_CI_AI” dönüyor.
    hangisini dikkate almalıyım?

    İyi çalışmalar..

37. Ahmet Kaymaz Says:
    Haziran 3rd, 2008 at 16:37

    Orhan Bey,

    ilginiz için teşekkür ederim. SQL Server’da tarih, sayı formatı gibi yerel bilgiler aktif user’in language bilgisine bağlıdır. Database’in collation bilgisiyle ilişkisi bulunmamaktadır. Sorguyu hangi kullanıcıyla sunucuya gönderiyorsanız o kullanıcının tarih formatı referans alınır. Örneğin dili Türkçe olan bir kullanıcı için aşağıdaki tarih formatı hata verir.

    DECLARE @Tarih Datetime
    SET @Tarih = ‘2008/12/31′
    PRINT @Tarih

    Aynı format, dili isveççe(Swedish-Svenska) olan kullanıcı için hata vermeyecektir.
    Çünkü Svenska için tarih formatı “ymd”, Türkçe için “dmy” şeklindedir.
    Bağlı olduğunuz kullanıcının hangi dile sahip olduğunu sizin de yazdığınız gibi @@LANGUAGE genel değişkenle öğrenilir. Hangi dilin handi formata sahip olduğunu da sp_helplanguage yordamından öğrenebilirsiniz.

    O anki güncel yani bağlandığını kullanıcı bilgisini SELECT SYSTEM_USER ile alabilirsiniz. Aynı şekilde aşağıdaki gibi küçük bir sorgulamayla o anki tarih formatını da okuyabilirsiniz.
    SELECT dateformat FROM master..syslanguages WHERE name=@@LANGUAGE

    Eğer girilecek tarih formatı aynı ve sadece sunucunun tarih formatı değişken olabiliyorsa her defasında sistem üzerindeki tarih formatını öğrenip ona göre sorgu oluşturma yerine acaba CONVERT() metodu ile standart bir tarih formatı oluşturmanız veya oturum esnasında “SET DATEFORMAT” komutuyla kendi tarih formatınızı belirlemeniz daha mantıklı olmaz mı.

38. osman kartal Says:
    Ekim 27th, 2008 at 23:58

    Verdiğiniz değerli bilgileri için çok teşekkür ederim
    Serverdaki dil problemine bir çözüm getirdim

39. Aynur Says:
    Kasım 17th, 2008 at 13:50

    Merhaba,
    DB’de collation’ı Cyrillic yaptım ve php ile verileri çektim. Ama explorerda veriler düzgün görülmüyor. Bunu nasıl çözebilirim? Php sayfası içerisine yazdığım verilerde sorun yok. Sadece db’den gelen veriler bozuk geliyor.

40. Ahmet Kaymaz Says:
    Kasım 17th, 2008 at 14:25

    Merhaba,

    Bahsettiğiniz collation sorunu MS SQL Server için mi yoksa MySql için mi geçerli. Veritabanındaki karakterleri okurken mi yoksa yazarken mi sorun çıkıyor. Öncelikle verilerin database tarafında doğru göründüğünden emin olmak gerekir. Eğer o tarafta doğru görünüyorsa sorun html sayfasının karakter yapısından kaynaklanıyor olabilir. Bir parça kod paylaşabilirseniz daha doğru bir çözüm üretebiliriz.

41. Aynur Says:
    Kasım 17th, 2008 at 14:32

    Db’ye kaydedebiliyorum.Hatta query analyser üzerinde select sorgusu ile verileri çekebiliyorum. PHP kodu içerisinde verileri db’den çektiğim zaman sorun çıkıyor. Mesela dönen kaydı echo $values[0]; diyerek ilk kaydı yazdırmaya çalışıyorum ve sonuç olarak ���������
    veya ?�??,.??????
    şeklinde karakterler çıkıyor. PHP sayfası içerisinde verileri yazıyorum ve düzgün şekilde görüntüleyebiliyorum. utf8 charset kullanıyorum sorunsuz görüntülüyorum. DB’den gelen kayıtlarda sorun var. Ben Rusçayı uygun bir windows cyrliic fontu ile çözdüm şimdi de Kazakça ile deneme yapıorum ve çözemedim. Kazakça da harici 8 karakter var onda sorun veriyor. Kafam karıştı iyice

42. Ahmet Kaymaz Says:
    Kasım 17th, 2008 at 15:53

    SQL Server için collation değerini doğru ayarlamak ve sözkonusu kolonların veri tipini unicode yapmak yeterli olmaktadır. Bundan emin olmak için de SQL Server içinde INSERT veya SELECT işlemi unicode olarak yapılır fakat Query Analyzer’dan bu verileri doğru okuduğunuzu söylüyorsunuz. Bu durumda sorun SQL Server’den değil PHP tarafından kaynaklanmaktadır. Bu da iki neden kaynaklanıyor olabilir. PHP’nin MSSQL’e bağlanmak için kullandığı driver’in özelliklerine bakmak gerekiyor gerçekten UTF-8 veya ilgili charset’i destekliyor mu. Bundan emin olmak için bir iki satırdan oluşan bir asp sayfası veya vbscript hazırlayıp sorunun PHP’den mi yoksa SQL Server tarafından mı kaynaklandığı öğrenilebilir. İkinci muhtemel durum da PHP server tarafından generate edilmiş olan HTML çıktının sayfa karakter kodu Kazakça’yı gösteremiyor olabilir.

43. Adem Uysal Says:
    Aralık 2nd, 2008 at 16:36

    Gerçekten oldukça yararlı bir çalışma. Teşekkürler.

44. ARTI Says:
    Aralık 18th, 2008 at 17:15

    Eline koluna sağlık gerçekten çok açık ve anlaşılır bir döküman olmuş. Teşekkür ederim.

Leave a Reply