---
title: "SQL Server SET LANGUAGE Turkish Tuzağı: Tarihleriniz Neden Yanlış?"
description: "Mikro ERP sorgularınız SSMS'de doğru çalışıyor ama web'den farklı sonuç mu veriyor? SET LANGUAGE Turkish ayarının tarih hesaplarını nasıl bozduğunu ve..."
date: 2026-04-12
category: mikro-erp
tags: ["sql-server", "mikro-erp", "tarih-format", "set-language", "localization", "bug"]
url: https://mikroerp.dev/blog/sql-server-set-language-turkish-tarih-tuzagi/
---

## Başınıza Geldi mi?

Cari yaşlandırma raporu çekiyorsunuz. SSMS'de sorgu düzgün çalışıyor. Aynı sorguyu web uygulamanızdan çalıştırıyorsunuz — sonuçlar tamamen farklı. Bakiyeler yanlış, dönemler kayıyor.

Saatlerce debug ettikten sonra suçluyu buluyorsunuz:

```sql
SET LANGUAGE Turkish
```

Bu tek satır, tüm tarih hesaplamalarınızı **sessizce** bozuyor.

## Sorun Ne?

SQL Server'da dil Türkçe ayarlanınca, tarih okuma sırası değişir:

```
İngilizce: 03/04/2024 → 4 Mart (Ay/Gün/Yıl)
Türkçe:    03/04/2024 → 3 Nisan (Gün/Ay/Yıl)
```

**Aynı tarih yazısı, iki farklı sonuç.** Ve SQL Server hiçbir hata vermez — sessizce yanlış tarihi kullanır.

## Neden Bu Kadar Sinsi?

- **SSMS'de fark etmezsiniz** — sunucunun dil ayarını kullanır
- **Hata vermez** — geçerli bir tarih üretirse sessizce devam eder
- **Bazen çalışır** — gün 12 veya altındayken her iki format da geçerli tarih üretir
- **13+ gün olunca patlar** — `13/01/2024` bir formatta geçersiz

```sql
SET LANGUAGE Turkish;

-- Bu çalışır (05 hem gün hem ay olabilir):
SELECT CONVERT(datetime, '05/06/2024');  -- 5 Haziran

-- Bu da çalışır AMA farklı yorumlanır:
SET LANGUAGE us_english;
SELECT CONVERT(datetime, '05/06/2024');  -- 6 Mayıs!
```

## Kesin Çözüm: Her Zaman ISO Formatı Kullanın

```sql
-- ✅ ISO format — dil ayarından bağımsız her zaman doğru çalışır
SELECT CONVERT(datetime, '2024-01-13', 120);  -- 13 Ocak, her yerde

-- ❌ Dil bağımlı — riskli
SELECT CONVERT(datetime, '13/01/2024');  -- Hangi format? Belli değil
```

### Web Uygulamanızda Ne Yapmalı?

Tarihleri JavaScript'te hesaplayıp SQL'e ISO string olarak gönderin:

```javascript
// ✅ Doğru yaklaşım
const bugun = new Date();
const oncekiAy = new Date(bugun);
oncekiAy.setDate(oncekiAy.getDate() - 30);

// ISO formatına çevir: 'YYYY-MM-DD'
const isoTarih = oncekiAy.toISOString().split('T')[0];

// SQL'e parametre olarak gönder
const sql = `SELECT * FROM cari_hareketler WHERE tarih >= @baslangic`;
request.input('baslangic', isoTarih);
```

## Güvenli CONVERT Style Kodları

| Style | Format | Güvenli? |
|-------|--------|:--------:|
| 120 | `2024-01-13 14:30:00` | ✅ |
| 112 | `20240113` | ✅ |
| 23 | `2024-01-13` | ✅ |
| 101 | `01/13/2024` | ❌ Dil bağımlı |
| 103 | `13/01/2024` | ❌ Dil bağımlı |

## Kontrol Listesi

- [ ] Tüm tarih string'leri ISO formatında mı? (`YYYY-MM-DD`)
- [ ] `CONVERT` fonksiyonlarında style 120 veya 112 kullanılıyor mu?
- [ ] Tarih hesaplamaları JavaScript'te yapılıp parametre olarak gönderiliyor mu?

## Biz Ne Yaşadık?

8 şubeli yapımızda cari yaşlandırma raporları tutarsız geliyordu. Sorunun kaynağı: Mikro ERP bağlantısında `SET LANGUAGE Turkish` aktifti ve proxy'den giden tarihler yanlış yorumlanıyordu. Çözüm: Tüm tarih işlemlerini JavaScript tarafına taşıdık, SQL'e sadece ISO string gönderdik.

## İlgili Yazılar

- [Mikro ERP Cari Yaşlandırma Otomasyonu](/blog/mikro-erp-cari-yaslandirma-otomasyonu/)
- [Mikro ERP'ye Web'den Güvenli Bağlantı](/blog/mikro-erp-web-baglanti-cloudflare-tunnel/)
- [fn_ Fonksiyonlarını Şubelere Kopyalama](/blog/mikro-erp-fn-fonksiyonlari-sube-kopyalama/)

---

*Bu yazı [AstaFlow Case Study](/case-study) serisinin bir parçasıdır.*