Ticari Yazılımlarda SQL Server 2022 ve Üzeri
* Kurmadan Önce Mutlaka Okuyun
Kapsam: Logo, Mikro ve benzeri yerel ticari ERP/ön muhasebe yazılımları
Neden Bu Makale Var?
Bu makale, sürekli tekrarlayan ve aynı hatalara yol açan SQL Server sürüm uyumluluk sorunlarına kalıcı bir çözüm getirmek amacıyla hazırlanmıştır.
Sahada karşılaştığımız tablo nettir: SQL Server 2022 veya 2025 kurulumu yapılan yerlerde, kısa süre içinde ticari yazılımlarda hatalar alınmaya başlanmakta, veri bütünlüğü sorunları yaşanmakta ve çözüm için tekrar bize dönülmektedir.
Önemli: Bu makale “SQL Server 2022/2025 kurmayın” demiyor. “Kurmadan önce aşağıdaki koşulları sağlayın; sağlayamıyorsanız kurmayın” diyor.
Karar sizindir, ancak sorumluluk da sizdedir.
Riskli 5 Kritik Nokta
1. Collation — 1254 (Türkçe) Kod Sayfası Şarttır
Yerel ticari yazılımların veritabanı yapısı, 1254 (Türkçe) kod sayfasını kullanır ve ç, ğ, ı, İ, ö, ş, ü gibi Türkçe karakterlerin doğru sıralanmasını ve karşılaştırılmasını sağlar.
SQL Server kurulumunda varsayılan olarak gelen Latin1_General_CI_AS ise 1252 kod sayfasını kullanır.
Bu harmanlama ile varchar alanlarda Türkçe karakterler bozulur; raporlarda ve sorgularda hatalı sonuçlar alırsınız.
Doğru seçim: Kurulumda Turkish_CI_AS veya Turkish_100_CI_AS (gerekirse _SC sonekli) seçilmelidir.
Kontrol komutu:
-- Logo veritabanları SELECT name, collation_name, compatibility_level FROM sys.databases WHERE name LIKE '%Logo%' ORDER BY name; -- Mikro veritabanları SELECT name, collation_name, compatibility_level FROM sys.databases WHERE name LIKE '%Mikro%' ORDER BY name;
2. UTF-8 Beta Ayarı — SQL Server Kurulumunda Kapalı Olmalıdır
Windows’ta “Beta: Dünya çapında Unicode UTF-8 desteği için kullan” seçeneği, legacy kod sayfası (1254) bekleyen ticari yazılımlarda encoding çakışmasına yol açar.
Sistem UTF-8’e zorlandığında, uygulama ile sunucu arasında kodlama uyumsuzluğu oluşur ve karakter bozulmaları, bağlantı hataları görülür.
Bu ayar kapalı tutulmalıdır. Ayrıca SQL Server kurulumunda UTF-8 collation (örneğin Turkish_100_CI_AS_SC_UTF8) seçilmemelidir.
UTF-8 collation desteği SQL Server 2019 (15.x) ve sonraki sürümlerde gelmiştir; ancak yerel ticari yazılımlar bu yapıyı henüz kullanmamaktadır.
Kontrol: Windows Bölge Ayarları → Yönetimsel → Sistem yerel ayarını değiştir → Beta UTF-8 seçeneği işaretsiz olmalıdır.
3. Compatibility Level — Yazılımın Beyan Ettiği Seviyede Tutulmalıdır
SQL Server 2022, compatibility level 160 ile gelir ve 160, 150, 140, 130, 120, 110, 100 seviyelerini destekler.
Ancak ticari yazılım üreticisi resmi olarak onaylamadığı sürece veritabanı uyumluluk seviyesi bu değerde bırakılmamalıdır.
Uyumluluk seviyesi yükseltildiğinde cardinality estimator değişiklikleri, query plan değişiklikleri ve yeni sorgu işleme davranışları devreye girer.
Bu değişiklikler mevcut raporlarda ve prosedürlerde performans düşüşüne veya hatalı sonuçlara yol açabilir.
Öneri: Veritabanının compatibility level’ı 130 (SQL Server 2016) veya 140 (SQL Server 2017/2019) seviyesinde bırakılmalıdır.
Yazılım üreticisinin destek ekibi aksini onaylamadıkça 150 veya 160’a yükseltilmemelidir.
4. UTF-8 Beta Ayarı Sadece SQL’i Değil, Tüm Sistemi Etkiler
Windows’taki “Beta: Dünya çapında Unicode UTF-8 desteği için kullan” ayarı, yalnızca SQL Server’ı değil, işletim sisteminin temel bileşenlerini de etkiler.
Bu ayar, sistemin varsayılan ANSI Kod Sayfası’nı (ACP) 65001 (UTF-8) olarak değiştirir.
Bu değişiklik, eski API’leri kullanan birçok uygulama ve servis için beklenmedik davranışlara yol açar.
Sahada karşılaştığımız sorunlar:
| Etki Alanı | Görülen Sorun |
|---|---|
| Windows API | “A” (ANSI) API’leri, bekledikleri kod sayfasını bulamaz; karakter bozulmaları, çökmeler |
| Lisans Servisleri | SQL Server, Logo, Mikro lisans servisleri başlamaz; “servis başlatılamadı” hataları |
| Dosya Sistemi | Dosya yolları ve içerikleri yanlış okunur; Türkçe karakterli dosya adları erişilemez hale gelir |
| Kurulum/Güncelleme Betikleri | SQL Server msdb110_upgrade.sql gibi betikler başarısız olur; servis hiç başlamaz |
| Üçüncü Parti Yazılımlar | muhasebe yazılımları çöker; karakter kodlama hataları raporlar |
| Sistem Kararlılığı | Bazı durumlarda mavi ekran ve sistem açılmama sorunları |
Neden bu kadar geniş etkili?
Modern uygulamalar Unicode (UTF-16) kullanırken, eski uygulamalar ve bazı sistem servisleri hâlâ 1254 (Türkçe) kod sayfasına bağımlıdır.
UTF-8 beta ayarı etkinleştirildiğinde, sistem genelinde bir uyumsuzluk zinciri başlar. Bu zincir, tek bir uygulamayı değil, tüm ekosistemi etkiler.
Kritik Uyarı: Bu ayar, SQL Server kurulumundan bağımsız olarak dahi sistemde sorun çıkarabilir.
Yani SQL Server hiç kurulmamış bir makinede bile bu ayar açıksa, lisans servisleri, dosya okuma işlemleri ve Windows API çağrıları bozulabilir.
Kontrol ve Düzeltme:
-
Win + R→intl.cpl→ Enter -
“Yönetimsel” sekmesi → “Sistem yerel ayarını değiştir”
-
“Beta: Dünya çapında Unicode UTF-8 desteği için kullan” seçeneği işaretsiz olmalıdır.
-
İşaretliyse kaldırın → Tamam → Sistemi yeniden başlatın.
Önemli: Bu ayar kapatıldıktan sonra dahi, daha önce oluşmuş veri bozulmaları (örneğin yanlış kaydedilmiş karakterler) kalıcı olabilir.
Bu nedenle ayarın kurulumdan önce kapalı olduğundan emin olunmalıdır.
5. BOM (Byte Order Mark) Sorunu ve Temiz Kurulum Gerekliliği
UTF-8 beta ayarı açıkken, bazı uygulamalar config/ini/xml dosyalarını BOM’lu UTF-8 olarak kaydeder.
Eski servisler bu BOM’u tanımaz ve servis başlamaz. Bu durumda yapılması gerekenler:
-
Uygulamayı kaldırın.
-
Data (veri) hariç tüm dosyaları silin. (Config, log, cache, temp klasörleri)
-
Windows UTF-8 beta ayarını kapatın (
intl.cpl→ Yönetimsel → Sistem yerel ayarı). -
Sistemi yeniden başlatın.
-
Temiz kurulum yapın.
Bu sıralama, BOM’lu dosyaların temizlenmesini ve yeni dosyaların doğru kod sayfasıyla (1254) oluşmasını sağlar.
- Data klasörünü silmeyin; veri kaybı yaşarsınız.
Not: Her servis başlamama sorunu BOM kaynaklı değildir. Önce Olay Günlüğü’nü (Event Viewer) kontrol edin; hata mesajı “config”, “encoding” veya “invalid character” içeriyorsa BOM sorunu muhtemeldir.
Gizli Tuzak: STRING_AGG ve Dokümantasyon Çelişkisi
STRING_AGG fonksiyonu, SQL Server 2016’da değil, SQL Server 2017 (14.x) ve sonraki sürümlerde kullanıma sunulmuştur.
Microsoft’un resmi dokümantasyonu, bu fonksiyonun “SQL Server 2017 (14.x) ve sonraki sürümler” için geçerli olduğunu açıkça belirtmektedir.
Yerel ticari yazılımların bazı modülleri STRING_AGG fonksiyonunu yoğun şekilde kullanmaktadır. Bu durumda:
-
SQL Server 2016 SP1 kurulu bir sistemde ilgili modüller “STRING_AGG is not a recognized built-in function name” hatası verecektir.
-
Kullanıcı, dokümana güvenerek 2016 SP1 kurar; ancak program çalışmaz.
-
Fiili minimum gereksinim SQL Server 2017’dir; dokümanlar ise 2016 SP1 demektedir.
Sonuç: Yazılım üreticilerinin dokümantasyonu bu konuda güncellenmemiştir ve fiili gereksinim SQL Server 2017 ve üzeridir.
Karar Ağacı: Hangi Durumda Ne Yapmalısınız?
| Durumunuz | Yapmanız Gereken |
|---|---|
| Yeni SQL Server kurulumu yapıyorsanız | Turkish_CI_AS + UTF-8 beta kapalı + compatibility level 130/140 |
| Mevcut SQL Server 2016 SP1 kullanıyorsanız | STRING_AGG hatası alıyorsanız 2017+’a yükseltme planı yapın |
| SQL Server 2022/2025 kurmak istiyorsanız | Yukarıdaki 5 kritik noktayı sağlayabiliyorsanız kurun; sağlayamıyorsanız kurmaktan kaçının |
| Mevcut 2022 kurulumunuz varsa | Collation, UTF-8 beta ve compatibility level’ı hemen kontrol edin; gerekirse düzeltin |
| Servis başlamıyor / uygulama açılmıyorsa | Olay Günlüğü’nü kontrol edin; BOM/encoding hatası varsa Bölüm 5’i uygulayın |
Kontrol Listesi: Kurulum Sonrası Doğrulama
Aşağıdaki sorguları çalıştırarak kurulumunuzun doğru yapılandırıldığını doğrulayın:
-- Beklenen: Turkish_CI_AS veya Turkish_100_CI_AS -- 2. Veritabanı harmanlaması ve uyumluluk seviyesi SELECT name AS VeritabaniAdi, collation_name AS Harmanlama, compatibility_level AS UyumlulukSeviyesi, SUSER_SNAME(owner_sid) AS Sahibi FROM sys.databases WHERE name LIKE '%Mikro%' OR name LIKE '%Logo%' ORDER BY name; -- Beklenen: Turkish_CI_AS / 130 veya 140 -- 3. tempdb harmanlaması (sunucu harmanlamasıyla uyumlu olmalı) SELECT name, collation_name FROM sys.databases WHERE name = 'tempdb'; -- 4. STRING_AGG fonksiyonu testi (2017+ gerektirir) SELECT STRING_AGG(name, ', ') AS TestSonucu FROM sys.databases; -- Hata verirse: SQL Server sürümü 2017'den düşüktür
5. Windows UTF-8 beta kontrolü (manuel):
Windows Ayarlar → Saat ve Dil → Bölge → Yönetimsel Dil Ayarları → “Beta: Unicode UTF-8 desteği” işaretsiz olmalıdır.
6. Notepad++ ile dosya kontrolü (isteğe bağlı):
Şüpheli config/log dosyasını Notepad++ ile açın. Sağ alt köşedeki kodlamayı okuyun.
ANSI görünüyorsa → Kodlama → Karakter Kümeleri → Türkçe → Windows-1254 seçerek Türkçe karakterlerin doğru görünüp görünmediğini test edin.
Sorumluluk Notu
Bu makalede belirtilen yapılandırma koşullarını sağlamadan SQL Server 2022 veya 2025 kurulumu yapanlar, doğacak veri bütünlüğü sorunlarından, uygulama hatalarından ve performans düşüşlerinden bizzat sorumludur.
Özet
| Konu | Doğru Uygulama |
|---|---|
| SQL Server sürümü | 2017+ (STRING_AGG nedeniyle); 2016 SP1 dokümanlarda geçse de fiilen yetersizdir |
| Collation | Turkish_CI_AS / Turkish_100_CI_AS |
| UTF-8 beta (Windows) | Kapalı; tüm sistemi etkiler, sadece SQL’i değil |
| UTF-8 beta (SQL) | UTF-8 collation seçilmemeli |
| Compatibility level | 130 (SQL 2016) veya 140 (SQL 2017/2019); üretici onayı olmadan yükseltilmemeli |
| BOM sorunu | Config/ini/xml dosyaları BOM’lu ise servis başlamaz; temiz kurulum gerekir |
| Kullanıcı adları | Türkçe karakter içermemeli; ASCII tercih edilmeli |
| 2022/2025 kurulumu | Koşullar sağlanıyorsa kurulabilir; sağlanamıyorsa kurulmamalı |
Bu makale, yerel ticari yazılım (Logo, Mikro ve benzeri) için kalıcı bir referans kaynağı olarak hazırlanmıştır. SQL Server 2025 ile ilgili güncellemeler yayınlandıkça revize edilecektir.