C# kitabı

--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

91 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. 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.

25. 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…..

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.

45. Ertuğrul KOMUT Says:
    Ocak 28th, 2009 at 17:17

    Date sorunu:
    Bütün ayarlamaları yaptım. SQLServer 2005, .net 3.5..

    SELECT @@LANGUAGE komutu sonunda Türkçe dönüyor.
    Fakat ‘25.01.2008′ parametrik SQL lerde bile format hatası veriyor…
    hatta
    “set dateformat dmy;insert into…
    şeklinde sql yazdığım da da “String was not recognized as a valid DateTime. ” hatasını alıyorum..
    Bir türlü çözemedim.

46. Ahmet Kaymaz Says:
    Ocak 28th, 2009 at 17:35

    Bu hata mesajı SQL Server’in değil .NET Framework’ün fırlattığı bir hata. Sanırım .NET kodu içerisinde Datetime türünde bir değişkeni set etmeye çalışıyorsunuz. C#, VB.NET diline göre daha hassas olduğu için özellikle tarihsel, sayısal verileri dönüştürmek yordamlarını kullanmanızı tavsiye ederim. DateTime tarih = “25/01/2008″; şeklinde tanımlanmış bir değişkeni işlemek için DateTime tarih = DateTime.Parse(“25/01/2008″); şeklinde DateTime.Parse() yordamını kullanmanız çözüm olabilir. Eğer sorunun SQL Server’den kaynaklandığını düşünüyorsanız öncelikle Query Analyzer’de T-SQL kodunuzun doğru çalıştığından emin olun.

47. serdar Says:
    Şubat 18th, 2009 at 14:39

    sql serverde tablo oluşturma yöntemleri diye bi araştırma yapmam gerekiyor ama çok karışık bilgiler verilmiş google de bulamadım acaba bi yardımcı olabilirmisiniz 4-5 maddeymiş galiba şimdiden tşk ederim herkese

48. Ahmet Kaymaz Says:
    Şubat 18th, 2009 at 15:24

    SQL Server üzerinde tablo oluşturmak için ya T-SQL’de aşağıdaki gibi CREATE TABLE komutunu kullanırsınız ya da Enterprise Manager / Management Studio gibi görsel bir araç aracılığıyla Tables sekmesini sağ tıklayıp “New Table” menüsünden yaparsınız.

    CREATE TABLE "table_adi"(
"kolon 1" "veri tipi 1",
"kolon 2" "veri tipi 2",
... )

49. baris Says:
    Mart 3rd, 2009 at 01:06

    Ahmet bey iyi çalışmalar,
    benimde sql server konusunda bir problemim var yukarıdaki anlatılanları okudum ve uygulayabileceklerimi uyguladım ancak sonuç değişmedi sql server – ASP tabanlı bir websitem var daha önce reg. settings \\\’i TR olan (windows ve sql server için) sunucuda duruyordu. Bu durumda sitede herhangi bir tr karakter sorunu yoktu. Şu an siteyi yurtdışında bir hostinge taşımak zorunda kaldım.

    Hosting te sql server desteği var ancak yönetiminde bazı kısıtlamalar sözkonusu.Eposta göndererek collation değerini turkish_ci_as şeklinde değiştirttim ancak select@@language sonucu us_english olarak dönüyor.

    websitesinde veritabanından gelen verilerde ş -> s ı -> i şeklinde değişiklikler oluyor. Bunu asp kodundan codepage vb değişiklikler yaparak düzeltebiliyorum ancak bu durumda da veritabanından gelmeyen verilerde karakter bozulmaları oluyor.

    Sizden ricam bana yurtdışı sunucundaki bu sql server için hangi ayarları yapmam gerektiği konusunda yardımcı olabilir misiniz?

    teşekkürler
    baris

50. Ahmet Kaymaz Says:
    Mart 3rd, 2009 at 08:43

    Barış Bey,

    Eğer sorun SQL Server ile ilgiliyse bu makale zaten sorunuzun yanıtını veriyor. “Eposta göndererek collation değerini turkish_ci_as şeklinde değiştirttim ancak select@@language sonucu us_english olarak dönüyor.“. Bunu yazdığınıza göre sanırım yazının tümünü okumadınız çünkü bu makaleyle asıl anlatmak istediğim language ile collation bilgilerinin aynı şey olmadığıdır. NVarChar, NText gibi kolonlara ASP içerisinden veriyi gönderirken verinin başına N karakterini ekleyip deneyebilir misini.z

    INSERT tablo (sutun) VALUES (N'Türkçe Veri')

51. seha Says:
    Mart 16th, 2009 at 12:27

    Ahmet bey öncelikle verdiğiniz bilgiler için teşekkür ediyorum…

    ticari bir yazılım kullandığımız programın veritabanında türkçe karakterlerle ilgili bir sorun yaşıyoruz. verdiğiniz bilgiler ışığında default dili ve database dilini türkçeye çevirdim fakat sorun devam etmekte. bir tabloda türkçe karakterler “ÝÞBANKASI ANT.ÞB”-”TAHSÝL ÇEKLERÝ” şeklinde değişirken, bir başka tabloda “IS BANKASI TAHSIL ÇEKLERI” şekliinde hiç türkçe karakter yokmuş gibi davranıyor. bu konuda bilgileriniz paylaşırsanız memnun olurum.

    İsmail Seha YÜCEL

52. Ahmet Kaymaz Says:
    Mart 16th, 2009 at 13:58

    Seha merhaba,

    öncelikle Türkçe karakter sorununun gerçekten SQL Server kaynaklanıp kaynaklanmadığını netleştirmeniz gerekiyor. Türkçe karakter veritabanının dil ayarıyla değil kolonun veri tipi ve collation değeriyle ilgilidir. İlk önce SQL Profiler aracından ticari yazılımın Türkçe karakterleri doğru göndermediğinden emin olmalısın. Ardından Query Analyzer’den tablodaki verilerin ham haline bakıp gerçekten Türkçe karakterlerin tabloda doğru durup durmadığına bakmak lazım.

    Eğer ticari yazılım karakterleri yanlış gönderiyorsa o tarafın düzeltilmesi gerekiyor. Eğer yazılım karakterleri veritabanına UNICODE olarak doğru gönderiyorsa o zaman SQL’deki tablodaki kolonların veri tip ve collation bilgilerini bu makalede anlatılanlara göre düzenlemelisin..

53. seha Says:
    Mart 16th, 2009 at 14:33

    öncelikle cevap yazdığın için teşekkür ederim…

    programda 2008 verilerinde herhngi sorunumuz yok, devir işlemi yaptıktan sonra 2009 verilerinde sorunyaşadık. programın yazılım destek bölümüyle görüştüğümde bu işin zor düzeltileceğinden söz ediliyor. şüphelerimden bir tanesi devir işlemi yaptığım terminalde işletim sistemi açılırken ingilizce uyarılar veriyor ama açılınca türkçe çalışıyor. bundan kaynaklanabilir diye düşünüyorum.
    ama yazdığın makaledekileri denedim dediğim gibi bir faydası olmadı vertabanını sağ tuş özellikler yaparsam dil türkçe görünüyor.

    ama tablolarda veriler yukarıda yazdığım şekilde çıkmakta.yine tablolar için çalıştıracağım komutlardan örnek verebilisen sevinirim…

    vakit ayırıp ilgilendiğin için teşekkür ederim…

    seha

54. Tarık Memil Says:
    Mart 17th, 2009 at 21:53

    Ahmet Bey merhaba,

    benim problemim biraz daha değişik
    elimde SQL 2005 server üzerinde çalışan birçok veritabanı var bunlar bir muhasebe programının veritabanları tüm COLLATE ler default olarak
    SQL_Latin1_General_CP1_CI_AS
    tanımlı. muhasebe programında verilerde herhangi bir problem yok raporlarda türkçe karakterler sorunsuz görüntüleniyor

    bu database ler muhasebe programına ait olduğu için ALTER ile COLLATION yapma şansım yok
    öyle yaparsam muhasebe programı verileri “?” ve değişik karakterler olarak algılıyor. ama
    bu yüzden benim sadece sorgu esnasında

    “SELECT ISYERI, SICILNO, TUR, ADI, SADI, CINSIYET, ADRES, DTAR, DYER, MERNISNO, UYRUGU, ASGDAHIL, ASGORAN
    FROM TBLES_COCUK
    ORDER BY ISYERI, SICILNO, TUR
    COLLATE Turkish_CI_AS”

    gibi bir sorgu ile karakterleri düzeltmem mümkün müdür?
    NOT:bu sorgu;
    “Msg 447, Level 16, State 0, Line 2
    Expression type tinyint is invalid for COLLATE clause.”
    şeklide bir hata veriyor

    şuan normal sorgularımda
    İ-Ý
    Ğ-Ð
    Ş-Þ
    olarak ekrana çıkıyor
    kullandığım platform ASP.net, dil VB
    sorguda kullandığım
    REPLACE(REPLACE((REPLACE[ISYERI],’Ý’,'İ’)),’Ð’,'Ğ’),’Þ’,'Ş’) AS [ISYERI]
    cümlesi de arama yaparken sorun çıkartıyor
    şimdiden teşekkürler hocam

55. Ahmet Kaymaz Says:
    Mart 18th, 2009 at 09:27

    Öncelikle REPLACE satırının hata vermesinin nedeni parantez eksikliğidir. Satırı aşağıdaki gibi düzeltirsen düzelecektir.

    REPLACE(REPLACE((REPLACE(ISYERI,’Ý’,'İ’)),’Ð’,'Ğ’),’Þ’,'Ş’) AS [ISYERI]

    “Expression type tinyint is invalid for COLLATE clause” hatası ise ORDER BY içerisindeki TUR kolonunun tinyint türünde olmasıdır. COLLATE sadece metin tabanlı veri türleri için kullanılabilir.

    Anladığım kadarıyla muhasebe programı Türkçe karakterleri SQL Server’e düzgün göndermiyor. Eğer böyleyse yani veritaba “Ş” harfi “Þ” olarak duruyorsa o zaman REPLACE fonksiyonuyla bunları tek düzeltmelisin. Aşağıdaki gibi bir fonksiyon işini görecektir.

    CREATE FUNCTION TurkceKarakter(
@Metin NVARCHAR(250)
)
RETURNS NVARCHAR(250)
AS
BEGIN
SET @Metin = Replace(@Metin,'ð', 'ğ');
SET @Metin = Replace(@Metin, 'Ð', 'Ğ');
SET @Metin = Replace(@Metin,'Ý', 'İ');
SET @Metin = Replace(@Metin,'Þ', 'Ş');
RETURN @Metin ;
END

56. Tarık Memil Says:
    Mart 18th, 2009 at 11:13

    öncelikle cevap için teşekkür ederim.
    replace yi buraya yanlış aktardım sanırım o sorgu hata vermiyor ben yazarken parantezi eksik yazmışım sadece bazı durumlarda bulması gerekeni bulmuyor yani sorgudan dönen verilerde problem oluyordu bende
    kendime göre arama yaptırdığım kutu içerisindeki
    kelimeleri arama yapmadan önce
    İ-Ý
    Ğ-Ð
    Ş-Þ
    olarak değiştirerek sorguya soktum yani ters mantıktan gittim arama problemim kalmadı
    collate olayına gelince ben sorguda genel anlamda bir collate kullanamıyormuyum yani tüm sorgudaki string veriler için geçerli olacak bir collate?
    yani
    “SELECT ISYERI COLLATE Turkish_CI_AS, SICILNO, TUR, ADI COLLATE Turkish_CI_AS, SADI COLLATE Turkish_CI_AS, CINSIYET, ADRES, DTAR, DYER, MERNISNO, UYRUGU, ASGDAHIL, ASGORAN
    FROM TBLES_COCUK
    ORDER BY ISYERI, SICILNO, TUR”

    şeklide field bazında mı collate kullanmam gerekiyor

    son olarak yazdığınız fonksiyon veritabanı üzerindeki bilgileri kalıcı olarak mı değiştiriyor yoksa sadece sorgu esnasında ekrana getirdiği verilerimi değiştiriyor
    çünkü dediğim gibi kalıcı bir değişiklik yapamıyorum ozaman muhasebe programı etkileniyor

57. Canan Oruç Says:
    Mart 18th, 2009 at 11:55

    Merhaba Ahmet Bey,

    Herşeyden önce bilgi paylaşımınız için teşekkür ederim.
    Benim sormak istediğim şey ayni tabloda hem Latin hem Cyrilic collation tanıtabilirmiyiz.
    Amacım ayni tabloda hem türkçe hem rusça karakterleri tutmak ve onları doğru yazıp okutmak.

    Syg.

58. Ahmet Kaymaz Says:
    Mart 18th, 2009 at 13:44

    Collation tablo bazında değil kolon bazında bir özellik olduğu için kolon seviyesinde işlem yapılabilir. Verdiğim fonksiyon dışarıdan aldığı metindeki karakterleri düzeltip Türkçeleştirilmiş halini döndürür. Fonksiyonu kaydedip SELECT dbo.TurkceKarakter(“að”) diye yazarsanız sonuç olarak “ağ” ifadesi döner. Bunu WHERE, SELECT, UPDATE gibi herhangi bir yerde kullanabilirsiniz.

59. Tarık Memil Says:
    Mart 18th, 2009 at 13:54

    teşekkür ederim

60. Ahmet Kaymaz Says:
    Mart 18th, 2009 at 21:02

    Sayın Oruç,

    aslında sorunun yanıtı mesajlarda mevcut . Şöyle anlatayım; Collation bilgisi tablo değil kolon seviyesinde bir özelliktir. Sorunu aynı kolonda hem Türkçe hem de Rusça karakterleri yazdırabilir miyiz diye düşünüyorum. Kolonun tipi char türündeyse o kolondaki collation bilgisi önem kazanmaktadır. Yani sadece collationa uyan değerler atanabilir. Örneğin char tipindeki kolonun collation değeri Turkish_CI_AI ise buraya Rusça karakterler ???? şeklinde saklanır. O yüzden bu kolonu Cyrillic_General_CI_AI olarak değiştirmek daha doğru olacaktır. Fakat kolonun tipi nchar, nvarchar gibi unicode destekli olursa çoğu zaman kolonun collation bilgisi önemli olmayıp tüm encoding karakterleri saklanabilir. Tabi burada dikkat edilmesi gereken konu SQL Server’e verileri atarken national character olarak bilinen “N” önekiyle aktarılması gerekir. Yani INSERT Table1 VALUES(N’мнопрстуфхцчш’) şeklinde olmalıdır.

61. harun Says:
    Mart 20th, 2009 at 02:02

    merhaba ahmet bey Query ye SELECT SERVERPROPERTY(‘collation’)
    sorgusunu çalıştırdığımızda SQL_Latin1_General_CP1_CI_AS
    değerini veriyor.Bunun Türkçe karakterlerde sorun çıkarmaması için Latin5 olması gerekir diye bir tavsiye aldık bu sorunu nasıl çözebiliriz acaba acemiye göre anlatırsanız minnettar kalırım saygılar

62. Ahmet Kaymaz Says:
    Mart 20th, 2009 at 12:09

    Harun Bey,

    mutlaka şu collation olacak diye bir durum bulunmamaktadır. Önemli olan veritabanınızın veri tiplerini düzgün yapmalısınız. Bunun için de bu makale ve yorumları sizi doğru yönlendirecektir. Türkçe karakter için SQL_Latin1_General_CP1254_CI_AS veya Turkish_CI_AS değerlerini seçip devam edebilirsiniz.

63. harun özden Says:
    Mart 21st, 2009 at 04:20

    Cevap için teşekkürler ahmet bey inanın bir çok arştırmama rağmen anca sizde yanıt bulbildim peki SQL_Latin1_General_CP1254_CI_AS veya Turkish_CI_AS değerlerini naıl belirlyoruz var olan bir veritabanı üzerinde bu değişiklği nasıl yaparız Saygılar..

64. Ahmet Kaymaz Says:
    Mart 21st, 2009 at 12:15

    Harun Bey,

    makalenin tümünü okumadığınızı düşünüyorum . Ayrıca 3.yorum sorunuzun yanıtını veriyor.
    Eğer mevcut bir kolonun collation değerini değiştirmek istiyorsanız bunu design bölümünden veya ALTER TABLE komutuyla T-SQL aracılığıyla yapabilirsiniz. Aynı şekilde veritabanının collation değerini değiştirmek için 3.yorumda anlatıldığı gibi ALTER DATABASE komutunu kullanabilirsiniz.
    Şunu unutmamalısınız; Database’in collation değerini değiştirmeniz mevcut tablolardaki kolonların collation değerini database default olarak değerlenmiş olsa bile etkilemez. Sadece bundan sonra oluşturacağınız kolonlar için database default seçili olduğu zaman yeni collation değeri atanır.

65. inanç Says:
    Haziran 16th, 2009 at 02:27

    Merhaba Ahmet Bey,
    Saat şu anda sabaha karsi 3:30 gibi ama ben hala sorunumu cözemedim ve burada 2-3 ay once kesilmis bir tartisma gördüm.Ben de gösterdiginiz ilgiden cesaret alarak bir soru sormak istiyorum.DotNetNuke ile çalışıyorum.Dotnetnuke kurulumu icin Latin1_General_CI_AS
    collation olarak gerekli. Bu yüzden kacamadigim sorgularimda

    SQL = “Select FIRMAADI,FIRMAID,BOLGEKODU From firma Where BOLGEKODU=1 and FIRMAADI LIKE N’” + prefixText + “%’ collate Turkish_CI_AS Order By FIRMAADI”;
    gibi sorgular yapiyorum. Ama kod nerede ise yazıldı ve bitti. Sorunun maalesef sonra farkına varabildim. Prosedürlerimi değiştirmem gerekiyor.

    ALTER PROCEDURE [dbo].[teklifAra]
    @BolgeKodu int,
    @FirmaAdi varchar(40)=null,
    @TeklifNo varchar(10)=null,
    @TeklifTar smalldatetime=NULL

    –EXECUTE teklifAra @FirmaAdi = N’Ba’,@BolgeKodu=1,@TeklifNo=null,@TeklifTar=’19000101′
    AS
    BEGIN
    SET NOCOUNT ON;
    SELECT [ID]
    ,[YIL]
    ,[FIRMA]
    ,[FAX]
    ,[MUSTNO]
    ,[TEKLIFTAR]
    ,[TEKLIFNO]
    ,[CIHAZADI]
    ,[OLCUMARALIGI]
    ,[KALYERI]
    ,[OLCMETODU]
    ,[BIRIMFIYAT]
    ,[ADET]
    ,[TOPLAMFIYAT]
    ,[TAHKALSURESI]
    ,[NOTLAR]
    ,[ILGILI]
    ,[ILGI]
    ,[ILGLAB]
    ,[ONAY]
    ,[TEKLIFSIRASI]
    ,[BASILDI]
    ,[BOLGEKODU],[ISTID] from teklif where
    BOLGEKODU=@BolgeKodu
    and ((@TeklifNo is null) or (TEKLIFNO like ‘%’ + @TeklifNo+’%’ ))
    and ((@TeklifTar=’1900.01.01′) or (TEKLIFTAR = @TeklifTar))
    and ((@FirmaAdi is null) or (FIRMA like ‘%’ + @FirmaAdi+’%’ ))
    –and ((@FirmaAdi is null) or (FIRMA like ‘%[N' + @FirmaAdi+']%’ COLLATE Turkish_CI_AS ))
    END

    hemen burada örnek bir tanesini verdim. Like için parametre aktarırken N prefix i nasıl kullanılabilir acaba?Bu sorunun üstesinden maalesef gelemiyorum.Teşekkur ederim

66. Ahmet Kaymaz Says:
    Haziran 16th, 2009 at 08:02

    Merhaba İnanç,

    kodun hepsini incelemedim ancak Unicode işlemin doğru çalışması için şunlara dikkat etmelisin;

    Teklif tablosundaki FIRMA gibi kolonların Unicode türü veri tiplerine (nchar,nvarchar,ntext) sahip olmalı.

    teklifAra isimli procedure içerisindeki @FirmaAdi parametresinin de Unicode olarak tanımlanmış olması gerekir. Yani FirmaAdi varchar(40)=null satırını FirmaAdi nvarchar(40)=null olarak değiştirelim.

    Son madde olarak bu procedure’in çağrıldığı yerde de veriyi N ile göndermek lazım. Yani EXEC teklifAra @BolgeKodu=1,@FirmaAdi=N’ABC’,@TeklifNo=123,@TeklifTar=’01/06/2009′

    Procedure içerisindeki parametreleri ve dışarıdan gönderilen değerleri Unicode olarak tanımladıktan sonra procedure içerisindeki LIKE alanlarına N yazmak gereksiz olacaktır. Tersinden düşünecek olursak parametreler Unicode olmadığı sürece içeride N kullanmış olmanın faydası olmayacaktır. LIKE alanlarındaki N’leri kaldırabilirsin.

    Kolay gelsin,

67. inanç Says:
    Haziran 16th, 2009 at 20:36

    Merhaba Hocam,
    Ben dün gece nerede ise hiç uyumadim..evet varchar yerine nvarchar kullaninca sorun çözüldü..varchar ve nvarchar arasinda ne fark var diye düşünüp duruyordum.Öğrendim! Ama ucuza olmadı. Siz çok kısa ve güzel biçimde açıklamışsınız. Beni gerçek bir sıkıntıdan kurtardınız.İçtenlikle teşekkür ediyorum..

68. Eyüp Says:
    Ağustos 10th, 2009 at 23:47

    parametre olarak N koymak hayat kurtardı sağolasın kral

69. Cem IŞIK Says:
    Eylül 12th, 2009 at 09:55

    Abi Tek Kelime Hayran Kaldım.2007 den bu yana herkese cevap yazmışın.Helal.

    Aslında Cevabını Yüz kere yazmışındır yukarıda ama bulamadım.
    veritabanım SQL_Latin1_General_CP1_CI_AS
    adsoyad diye bi alanım var orda “Cem Işık” yazıyor.
    Ne yaptımsa vb.net te sorguyla getiremedim o alanı.
    select * from tabloadi where adsoyad=’Cem Işık’ olmuyor yani.
    19 numaralı cevabına göre yaptım sonuç alıyorum ama benimde içime sinmiyor şöyle bi sorgu.

    select * from tabloadi where adsoyad collate French_CI_AI=’Cem Işık’

    veritabanını Turkish_CI_AS felan yapamıyorum çünkü Netsis veritabanından Viewlere bilgi alıyorum.
    Netsisde SQL_Latin1_General_CP1_CI_AS.

    Ne yazarsam onu gösterecek şekilde nasıl bi uyarlama yapabilirim acaba?

70. Ahmet Kaymaz Says:
    Eylül 13th, 2009 at 09:53

    select * from tabloadi where adsoyad=’Cem Işık’ cümlesindeki adsoyad kolonunun collation değerini yazmış olsaydın daha iyi yardımcı olabilirdim. Eğer o kolonun collation değeri SQL_Latin1_General_CP1_CI_AS
    ise herhangi bir sorun olmaması WHERE ile birlikte collate kullanmana gerek kalmadan doğru çalışması gerekeir. French_CI_AI değerinin ne ilgisi var.

71. Cem IŞIK Says:
    Eylül 15th, 2009 at 10:14

    Sorumu tekrarlıyım o zaman.
    Veritabanı : SQL_Latin1_General_CP1_CI_AS
    Tablo : SQL_Latin1_General_CP1_CI_AS
    adsoyad: database default

    Baglanti Cümlesi : Provider=SQLOLEDB;password=*****;User ID=sa;Data Source=serveradi; Initial Catalog =tabloadi;Persist Security Info=True;Auto Translate=False;

    Sorgu : select * from tabloadi where adsoyad=’Cem Işık’;
    Sonuç : boş
    Ama Sorgu : select * from tabloadi where adsoyad collate French_CI_AI=’Cem Işık’;
    olursa
    Sonuç : Cem Işık

72. Ahmet Kaymaz Says:
    Eylül 17th, 2009 at 10:36

    Bu sorguları SQL Server Query Analyzer’da çalıştırdığın zaman tablodaki değerin gerçekten ne olup olmadığına bakmak lazım. adsoyad kolonunun unicode veritipine (nchar,nvarchar) sahip olduğunu düşünerek “Cem Işık” değeri bu yapıda unicode olarak kayıt edilmemişse “Cem Isik” olarak görünüyor olabilir. adsoyad kolonunun unicode veritipine sahip olduğunu düşünerek

    select * from tabloadi where adsoyad=’Cem Işık’

    yazdığınızda “Cem Isik” kaydının geliyor olması lazım. Doğrudan “Cem Işık” getirmesi için N önekini kullanmalısınız.

    select * from tabloadi where adsoyad=N’Cem Işık’

    Eğer bu sorgu da onu getirmiyorsa yapacak birşey yok sanırım. Bu arada bu kayıtların INSERT tabloadi VALUES (N’Cem Işık’) olarak kayıt ediliyor olması gerekmektedir.

73. Orkun Türk Says:
    Ekim 1st, 2009 at 12:07

    Ahmet Bey
    Paylaşımınız oldukca güzel sizden bir ricam olucaktı yakın zamanda SQL SERVER 2005′te Crystal Report’un nasıl çalıştıgını paylaşırsanız cok sevineceğim.

    şimdiden teşekkürler

    Orkun…

74. GÜRCAN Says:
    Kasım 8th, 2009 at 18:11

    merhaba sql server 2008 actıgımda sunucu adı üzerinde sağ tuş proportions dediğimde general bölümünde server colletion var orda kurulurken latin şeçilmiş ve ben onu nasıl türkçe yaparım acaba. kurulumda defeult dıl ayarı bu SQL_Latin1_General_CP1_CI_AS
    ben bunu dırek olarak Turkish_CI_AS yapmak istiyorum nasıl yaparım acaba

75. kerim Says:
    Kasım 16th, 2009 at 19:00

    hocam neden phpde 1i silince yeni yazılan şey 1e deilde yeni bi rakama yazılıo yada neden 1i silince sıralama kaymıyo

76. Ahmet Kaymaz Says:
    Kasım 17th, 2009 at 21:32

    Kerim, keşke seni anlayabilseydim. Sanırım identity değerli bir kolondan bahsediyorsun. Bu tür kolonlarda daha önce verilmiş değer yeniden verilmez. Ancak manual bir şekilde öteleme veya sıralamayı yeniden düzenlemek lazım.

77. Fatih ÖZDEMİR Says:
    Aralık 16th, 2009 at 18:03

    COLLATE bundan daha kısa ve anlaşılır anlatılamz her halde.. teşekkürler

78. Orkun Says:
    Ocak 15th, 2010 at 23:44

    Merhaba Ahmet Bey
    ben sql 2000 kullanmaktayım. dbm de ılgın diye alınan bir üyelik ilgin olarak görünmekte ancak ilgin ve ılgını ayrı ayrı kayıtta olmasını istiyorum. ılgın diye kaydetsem dahi dm ye ilgin olarak kaydolmakta. dil : latin1_general_cp1_CI_AS durumunda. Hangi dile çevirmem gerekir ki ılgın ve ilgin iki farklı kayıt olabilisin. Teşekkürler

79. Göktuğ Akçay Says:
    Ocak 18th, 2010 at 13:29

    Öncelikle Bu mükemmel içerikler için size teşekkür etmek istiyorum Ahmet Bey .. Gerçekten çok yardımcı oldu bana bu bilgiler bu işte tecrübeli değilim bilmediğim öğreneceğim çok şeyler var daha … benim sorum şu olucak size ;

    Bir sitemin veritabanına sunucusunda olan sıkıntılardan dolayı sürekli ulaşamıyorduk ve site sürekli kapanıyordu ve sunucusunu değiştirdi hosting firması ve yeni sunucuya taşıdılar bende siteyi yeni sunucunun ip leri ile güncelledim ve veritabanını ordan çekiyor şimdi fakat ekleme güncelleme gibi işlemler yapacağım zaman veritabanına şöyle bir hata veriyor ..

    Microsoft OLE DB Provider for ODBC Drivers error ‘80004005′

    [Microsoft][ODBC SQL Server Driver][SQL Server]Could not find server ‘SQL2005-01′ in sys.servers. Verify that the correct server name was specified. If necessary, execute the stored procedure sp_addlinkedserver to add the server to sys.servers.

    icerikEklendi.asp, line 105

    Line 105 >> rsAdmin2.update()

    ilgili kodlar ;

    set rsAdmin2 = server.createobject(“ADODB.recordset”)
    rsAdmin2.open “H_DUYURU”, adoCon, 2, 2

    Bu hatanın anlamı nedir acaba yardımcı olabilirmisiniz ?

80. Göktuğ Akçay Says:
    Ocak 18th, 2010 at 16:01

    Ahmet bey sizden bir konuda daha yardım isteyeceğim şimdiden teşekkür ederim yardımlarınız için ..

    yine aynı sitenin veritabanının sunucusunda sorun oluştu ve sunucu değiştikten sonra yeni sunucuya geçince sitede veritabanından çekilen resimlerde sorun oldu resimler görünmüyor ama görünmeyen resimler adında türkçe karakter olan resimler ( İ,Ş ve Ğ ) olan resimler veritabanında örneğin ALİİĞDE.jpg olarak kayıtlı bu resim sitede önceden görünüyodu fakat sunucuda sorun olduktan sonra resimler görünmemeye başladı zağ tıklayıp resimin yolna baktığımda ALIIGDE.jpg olarak bakıyor veritabanına ve bulamayınca göstermiyor haliyle … veritabanının Collation ‘ u Turkish CI_AS
    sunucunun Collation ‘ u SQL_Latin1_CP1_CI_AS

    bu sorun için nasıl bi çözüm öneriniz var acaba ahmet bey ?

81. Ahmet Kaymaz Says:
    Ocak 20th, 2010 at 08:53

    Orkun merhaba,

    Bu duruma tablonun collation değerinin SQL_Latin1_General_CP1_CI_AS olmasından kaynaklanmamaktadır. Bu collation ılgın değerini ilgin yapmaz. Veritabanına kayıt eden programda bir sorun var bence. Doğrudan Query Analyzer’de INSERT ile tabloya “ılgın” değerini yazmayı denedin mi.

82. Ahmet Kaymaz Says:
    Ocak 20th, 2010 at 09:00

    Göktuğ,

    il sorunun yanıtı sanırım SQL Server üzerinde bir linked server / remote server kurmuşsunuz. Adı “SQL2005-01″ olan bu uzak sunucuya erişemiyor.

    2.sorunun yanıtı için şunu söyleyebilirim;sunucu veya db’nin collation değerinden ziyade verinin bulunduğu tablonun collation değeri önemlidir. sp_help TabloAdi olarak sorgularsan oradaki kolonları ve collation değerlerini listeler. Sözkonusu resim kolonunun collation değeri Turkish_CI_AS ise hiçbir sorun çıkmaz. Query Analyzer ile SELECT cümlesini çalıştırdın mı. Orada da Türkçe karakter sorunu var mı. Eğer yoksa ASP.NET’te ayarlardan kaynaklanıyordur. Ya da zayıf bir ihtimal taşınma esnasında veri bozuldu.

83. Deniz Kuran Says:
    Ocak 21st, 2010 at 20:44

    Merhaba Ahmet Bey, öncelikle makaleleriniz için teşekkürlerimi dile getirmek istiyorum.

    Ben şöyle bir sıkıntı ile karşı karşıyayım.

    ASP ile hazırladığım web uygulamalarında database bağlantılarını (SQL 2000) global.asa içerisinde sağlamıştım. SQL 2000′e web üzerinden bağlantı kurmak için “webuser” adında bir SQL kullanıcısı yaratmıştım. Bu kullanıcının “Default Language” değerini ise “turkish” olarak belirledim. IIS root klasöründe test.asp içerisine “response.write(Session.LCID)” satırını yazıp ekrana değerini bastırdığım zaman 1055 değeri geliyor. Buradan SQL’e bağlantıyı “Türkçe” olarak yaptığımı anlıyorum. Buraya kadar bir sıkıntım yok. Tüm uygulamalarım düzenli bir şekilde çalışıyor. Fakat bu aralar sistemimi SQL 2005′ e geçirmek istedim. Aynı database kullanıcısını SQL 2005 üzerinde tekrar yarattım ve Default Language değerini turkish olarak belirledim. Ama bir türlü database bağlantısını türkçe olarak sağlayamadım. Test için yarattığım test.asp dosyasında LCID değerini ekrana yazdırdığım zaman 1033 çıkıyor. Böyle olunca da cdate() hataları alıyorum. Aynı sistem üzerinde SQL 2005′i silip tekrar SQL 2000′i kurduğum zaman sorun olmuyor. SQL 2005 üzerinde bu kulanıcının turkish değeri ile bağlantı kurmasını nasıl sağlayabilirim?

    “ALTER LOGIN webuser WITH DEFAULT_LANGUAGE = Turkish” ifadesi ile de güncelleme yaptım. Sonuç aynı.

    Bu konuda yardımcı olursanız sevinirim. Şimdiden teşekkürler…

84. Ahmet Kaymaz Says:
    Ocak 22nd, 2010 at 09:30

    Deniz,

    CDate() fonksiyonu VBScript ile ilgili olup SQL ile herhangi bir ilişkisi olmadığı için sorun SQL Server’den değil Web sunucudaki ayarlardan kaynaklanmaktadır. Sayfanın başına Session.LCID = 1055 satırını eklerseniz o oturumdaki yerel ayarların Türkçe olacağını düşünüyorum.

85. Deniz Kuran Says:
    Ocak 22nd, 2010 at 11:52

    Teşekkür ederim cevabınız için Ahmet bey.

    Sorunu söylediğiniz şekilde halledebilirim. Ama kafamı kurcalayan şu. SQL Server üzerinden oturum açan kullanıcının dilini yukarıda anlattığınız şekilde “Default Language” ile belirliyoruz. Ve yarattığımız bu kullanıcıyı Connection String’te kullandığımız zaman SQL’e bu kullanıcının “Türkçe” dil ayarları ile bağlanacağını söylemiş oluyoruz yanılmıyorsam. Bu da, bu oturumdan gelecek tarih, para vb. değerlerin SQL tarafından hangi formatta algılanacağını belirtiyor. Dolayısıyla CDATE fonksiyonu ile ben veritabanına gg.aa.yyyy formatında bir değer gönderdiğim zaman SQL üzerinde oturum açan kullanıcının dili “Türkçe” olduğu için SQL bu formata göre işlem yapacaktır. Buraya kadar umarım doğru yanılmıyorumdur.

    Bu sorun SQL 2000′de olmuyor. Çünkü veritabanına bağlantı kuran kullanıcının dili türkçe. Ve ben web üzerinden CDATE() ile fonkiyonu ile gg.aa.yyyy olarak tarih gönderdiğimde SQL bu değeri sorunsuz bir şekilde update ediyor. Ama SQL 2005′de aynı kullanıcıyı türkçe dil değeri ile yaratıp bağlantı kurduğumda, CDATE() ile gg.aa.yyyy formatında tarih gönderdiğimde SQL bu kullanıcıdan gelecek tarih değerini türkçe beklemiyor, ingilizce bekliyor. Yani aa/gg/yyyy olarak beklediği için sistem burada sorun yaratıyor. Çünkü ben hiç bir sayfamda LCID tanımı yapmadan SQL 2000 ile sorunsuz bir şekilde çalışıyorum. Büyük bir ihtimalle SQL 2005′te yarattığım bu kullanıcının dil ayarlarında bir sorun var.

86. Ahmet Kaymaz Says:
    Ocak 22nd, 2010 at 16:28

    Sözkonusu connection string ile “SELECT @@LANGUAGE” ifadesini çalıştırdığınızda “Türkçe” değeri dönüyorsa aşağıdaki formatlarda bugünün tarihini girebilirsiniz.

    INSERT Table(Tarih) VALUES(‘22.01.2010′)
    INSERT Table(Tarih) VALUES(‘22/01/2010′)
    INSERT Table(Tarih) VALUES(‘22-01-2010′)

    Bence ASP’de oluşturduğunuz SQL cümlesini ekrana yazdıran veya SQL Profiler aracıyla SQL Server’e tam olarak nasıl bir ifadenin gittiğine bakınız. Eğer veritabanına bağlı olduğunuz kullanıcının varsayılan dil ayarından emin değilseniz kullanıcının o anki oturumunda geçici olarak dili değiştirmek için SET LANGUAGE anahtarını kullanabilirsiniz.

87. Selman Gezici Says:
    Şubat 18th, 2010 at 22:00

    Çok güzel bir yazı olmuş. Ne kadar teşekkür etsem azdır.

88. murat Says:
    Nisan 19th, 2010 at 23:42

    ahmet bey oncelikle aciklayici bilgileriniz icin cok tesekkurler.Ahmet bey bir soru sormak istiyorum.
    mssql server turkish collation ve turkish database ayarlari ile bir program kullaniyordum.program surum yenileyince sql in yedegini alip restore ettim.fakat programin yeni surumunde servera latin dil ayarlari ile yukleme yapılması gerekiyormus.yani mssql server collation latin olmali.aksi takdirde calistirmiyor.simdi ben daha onceki databasemi yeni sürüm convert edemedigi icin calistiramiyorum.latini turkce collationa ceviremiyor.bana bu konuda yardimci olabilirmisiniz.
    Selamlar.

89. Ahmet Kaymaz Says:
    Nisan 26th, 2010 at 18:56

    O zaman elindeki veritabanını restore edip veritabanının collation değerini istediğin şekilde değiştirebilirsin. Ardından programa bu yeni restore edilmiş veritabanını gösterirsen işlem düzelir diye düşünüyorum.

90. Elif Alev Says:
    Temmuz 27th, 2010 at 08:59

    Merhaba,

    Ben azeri latin harfleriyle datalar girmek istiyorum,sql server 2005 kullanıyorum, Azeri_Latin_90_CI_AS collation’ı set edilmiş ve tüm stringler nvarchar() olmasına rağmen yabancı olan tek harfi(azerinin türkçeden tek farklı harfi var) ? olarak görüyorum.Yardımcı olabilirseniz çok sevinirim teşekkürler..

91. Ahmet Kaymaz Says:
    Temmuz 28th, 2010 at 18:32

    Verileri unicode olarak girmeniz yani değerin başına N eklemeniz gerekmektedir. N’цкий′ gibi.

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

Security Code: