İstemci kod sayfası sunucu kodu sayfasından farklıysa SQL Server ODBC sürücüsünü kullanarak karakter verilerini bir istemciden sunucuya doğru şekilde çeviremezsiniz

Bu makale, SQL Server ODBC sürücüsü kullanılırken istemci verilerinin yanlış çevirisine neden olan bir sorunu geçici olarak çözmenize yardımcı olur.

Özgün ürün sürümü: SQL Server
Özgün KB numarası: 234748

Belirtiler

SQL Server ODBC sürücüsünün MDAC 2.1 veya sonraki sürümünü (sürüm 3.70.0623 veya üzeri) veya OLEDB sağlayıcısını (sürüm 7.01.0623 veya üzeri) kullanırken, bazı durumlarda bağlantı için devre dışı bırakıldığında Autotranslation bile karakter verilerinin istemci kodu sayfasından sunucu kodu sayfasına çevirisi ile karşılaşabilirsiniz.

Neden

Autotranslation kod sayfası dönüşümüne neden olabilecek tek mekanizma değildir. SQL Server 7.0 ODBC sürücüsü ve OLEDB sağlayıcısı, MSDE 1.0, SQL Server 7.0 veya sonraki sürümlerine bağlanırken yeni bir davranışa neden olur. Dil olayı olarak gönderilen tüm SQL deyimleri, sunucuya gönderilmeden önce istemcide Unicode'a dönüştürülür. Bitiş etkisi, bağlantının geçerli Autotranslation ayarından bağımsız olarak istemciden bir dil olayı aracılığıyla sunucuya akan tüm verilere benzerAutotranslation. SQL Server'ın kod sayfası dışında bir kod sayfasından çevrilmemiş karakter verilerini depolamaya çalışma dışında herhangi bir zorluk oluşturmaz.

Geçici çözüm

Kod sayfası X verilerini Y SQL Server kod sayfasında depolamayın (örneğin, kod sayfası 950 verileri bir kod sayfası 1252 sunucusunda). Bu bazı durumlarda SQL Server'ın önceki sürümlerinde mümkün olsa da, her zaman desteklenmiyordu. 1252 SQL Server'da, 1252 karakteri dışındaki her şey geçerli karakter verileri değildir. Farklı bir kod sayfasındaki Unicode olmayan karakter verileri doğru sıralanmaz ve çift baytlı (DBCS) veriler söz konusu olduğunda SQL Server karakter sınırlarını doğru tanımaz. Önemli sorunlara neden olabilir.

SQL Server'ın kod sayfası için en iyi seçenek, sunucuya erişecek istemcilerin kod sayfasıdır.

Sunucu ve istemcinin farklı kod sayfaları olabilir, ancak her durumda sunucunun kod sayfasına ve bu sayfadan doğru veri çevirisi elde etmek için istemcide Otomatik aktarım'ın etkinleştirildiğinden emin olmanız gerekir.

Sunucunuzun birden çok kod sayfasından veri depolaması gerekiyorsa, desteklenen çözüm verileri Unicode sütunlarında (NCHAR/NVARCHAR/NTEXT) depolamaktır.

Durumunuz için kod sayfası X verilerini Y SQL Server kod sayfasında depolamanız gerekiyorsa, bunu güvenilir bir şekilde yapmanın yalnızca iki yolu vardır:

• Verileri ikili sütunlarda (BINARY/VARBINARY/IMAGE) depolayın.
• Uygulamanızı, karakter verileriyle ilgilenen tüm SQL deyimleri için Uzaktan Yordam Çağrılarını (RPC) kullanacak şekilde yazın. RPC olayı aracılığıyla gönderilen veriler dönüştürmeye tabi değildir. Sürücü veya DSN düzeyinde, gönderilen olayların türünü değiştirmek için yapabileceğiniz hiçbir şey yoktur. Bir komutun dil olarak mı yoksa RPC olayı olarak mı gönderileceği tamamen uygulama yazıldığında programcı tarafından seçilen API'lere ve söz dizimine bağlıdır.

Daha Fazla Bilgi

Otomatik aktarım (diğer bir ifadeyle , daha yeni ODBC uygulamalarında karakter verileri için Çeviri Yap onay kutuları), verileri sunucuya göndermeden önce istemci kodu sayfasındaki karakter verilerini sunucu kodu sayfasına dönüştürür ve Unicode'ı çeviri ortamı olarak kullanır. Ancak, 3.7 SQL Server ODBC sürücüsü ayrıca dil olayı olarak gönderilen tüm SQL deyimlerini kabloya yerleştirmeden önce Unicode'a dönüştürür. Bu, Otomatik aktarıma benzer ancak Otomatik aktarım ayarı tarafından yönetilmeyen bir etkiye sahiptir. Buna karşılık, sunucudan istemcilere geri akan karakter verileri Otomatik aktarım bayrağına dikkat eder; Otomatik aktarım kapalıysa, veriler istemci uygulamasına sunucudaki verilerle aynı karakter kodlarıyla ulaşır. Benzer şekilde, istemciden sunucuya RPC olayları için verilerin çevirisi, Otomatik aktarım kapatılarak devre dışı bırakılabilir. Davranışın dil olaylarını nasıl etkilediğini gösteren basit bir betik aşağıda belirtilmiştir. Bu örnek, kod sayfası 437 sunucusuna bağlanan bir kod sayfası 1252 istemcisinde Sorgu Çözümleyicisi'nden çalıştırıldı:

-- Turn Autotranslation off here.
 USE tempdb
 GO
 CREATE TABLE t1 (c1 int, c2 char(1))
 GO

-- Enter a yen character, using the keystroke ALT-0165.
 INSERT INTO t1 VALUES (1, '¥') 
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1  157

(1 row(s) affected)

Yukarıdaki örnek hakkında aşağıdakiler:

• Bu toplu işlem sırasında kapalı olsa Autotranslation da, 165 karakter kodu (yen in code page 1252) 157'ye (yen in code page 437) dönüştürüldü. Bunun nedeni, ODBC sürücüsünün SQL dizesini sunucuyu göndermeden önce Unicode'a dönüştürmesi, dolayısıyla sunucunun bunu kod sayfası 437'deki depolama için uygun karaktere dönüştürebilmesidir.
• İstemci depolanan verileri almak için bir SELECT çalıştırdığında, 157 karakteri istemcide çevrilmeyen bir şekilde geldi (157, kod sayfası 1252 istemcisinde '' kutusu olarak gösterilir). Bunun nedeni, bu makalede açıklanan dönüştürmenin sunucudan istemciye değil yalnızca istemciden sunucuya gönderilen veriler için geçerli olmasıdır. Ayar kapalı olduğundan Autotranslation veriler çevrilmedi.

-- Turn Autotranslation back on before running the following batch.
 INSERT INTO t1 VALUES (2, '¥')
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1 ¥ 157
 2 ¥ 157

(2 row(s) affected)

Bu durumda, yeniden açmanın Autotranslation istemciden sunucuya çeviri üzerinde hiçbir etkisi yoktu (yani, 165 karakter kodundan 157 karakter koduna aynı doğru çeviri gerçekleşti), ancak sunucudan alınan veriler üzerinde bir etkisi oldu. SELECT deyimi bu kez çalıştırıldığında (with Autotranslation on), yen sembolleri kod sayfası 1252 uygulamasında doğru şekilde görüntülenir çünkü bunlar mekanizma tarafından Autotranslation 157 karakter kodundan 165 karakter koduna geri çevrilmiştir.

Herhangi bir SQL Server ODBC sürücüsü sürüm 3.70 veya üzerini kullanırken ve SQL Server 7.0 veya sonraki bir sürüme bağlanırken bu davranışı (dil olaylarının istemcide Unicode'a dönüştürülmesi) görürsünüz. Eski ODBC sürücüleri kullanılırken veya SQL Server 6.5 veya önceki sürümlerine bağlanmak için 3.7 sürücüsü kullanılırken oluşmaz. Ayrıca, verilerinizi Unicode sütunlarında (NCHAR/NVARCHAR/NTEXT) depoluyorsanız dönüştürme işlemi sorun oluşturmaz.

Sql Server 2005'te karakter verilerinin nasıl temsillendiği hakkında daha fazla bilgi için bkz . İstemci bilgisayarın kod sayfası SQL Server 2005'teki veritabanının kod sayfasından farklı olduğunda karakter verileri yanlış temsil edilir.