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

Bu makale, SQL Server ODBC sürücüsü kullanı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 kod sayfasından sunucu kodu sayfasına çevirisini yaşayabilirsiniz.

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 kod sayfası dışında bir kod sayfasından çevrilmemiş karakter verilerini depolamaya çalışma dışında hiçbir zorluk getirmez.

Geçici Çözüm

Kod sayfası X verilerini Y SQL Server kod sayfasında depolama (örneğin, kod sayfası 950 verileri bir kod sayfası 1252 sunucusunda). Bu, bazı durumlarda SQL Server'nin önceki sürümleriyle mümkün olsa da, her zaman desteklenmiyordu. 1252 SQL Server 1252 karakteri dışında hiçbir ş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 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 doğru şekilde veri çevirisi yapmak için istemcide Otomatik aktarım'ın etkinleştirildiğinden emin olmanız gerekir.

Sunucunuz birden çok kod sayfasından verileri depolamak zorundaysa, 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.
• Karakter verileriyle ilgilenen tüm SQL deyimleri için Uzak Yordam Çağrılarını (RPC) kullanmak üzere uygulamanızı 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 veya RPC olayı olarak gönderilip gönderilmediğ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 kod sayfasındaki karakter verilerini sunucu kodu sayfasına dönüştürür ve unicode çeviri ortamı olarak kullanılır. Ancak, 3.7 SQL Server ODBC sürücüsü, 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 de Otomatik aktarım kapatılarak devre dışı bırakılabilir. Davranışın dil olaylarını nasıl etkilediğini gösteren basit bir betik. Bu örnek, bir 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 (kod sayfasında yen 1252) 157'ye dönüştürüldü (kod sayfasında 437 yen). Bunun nedeni ODBC sürücüsünün SQL dizesini sunucuyu göndermeden önce Unicode'a dönüştürmesi ve dolayısıyla sunucunun bunu kod sayfası 437'de 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 yapılan çeviri üzerinde hiçbir etkisi olmadı (yani, 165 karakter kodundan 157 karakter koduna doğru çevirinin aynısı gerçekleşti), ancak sunucudan alınan veriler üzerinde bir etkisi oldu. SELECT deyimi bu kez çalıştırıldığında (ile Autotranslation ), yen sembolleri mekanizma tarafından Autotranslation 157 karakter kodundan 165 karakter koduna çevrildiğinden kod sayfası 1252 uygulamasında doğru şekilde görüntülenir.

SQL Server ODBC sürücüsü 3.70 veya sonraki bir sürümünü 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 bir sürüme bağlanmak için 3.7 sürücüsünü kullanırken gerçekleşmez. 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.