Şimdi ağır bir bedelle öğrendiğim, ancak aslında çok basit olan bir problemi ve çözümünü anlatmak istiyorum..
Omuzlarıma o ağır yükü bindiren ve bana saatlerce tırmalattıran o sistem mühendislerine ithafen olsun 🙂
Sıradan bir gündü ve sıradan bir şekilde yoğun iş temposunda çalışıyorduk.. Müşterilerimizden birinde çalışmakta olan çok kritik bir uygulamanın veritabanı, MS SQL Server 2005 ‘ten MS SQL Server 2008 R2 ye yükseltilmişti, performans amacıyla (!) Bütün özelliklerini aynen kopyaladık, sadece yükseltme yaptık diye bildirilmişti bize. Nereden bilebilirdim ki (!) o sistem mühendisi arkadaşların alanlarında çok uzman(!) olduklarını.. DB Server Login kullanıcılarını script ile kopyalamayı akıl ettiklerini nereden bilebilirdim.
Neyse, daha fazla hikaye anlatmadan soruna döneyim ben. Uygulamamızın en kritik noktasında, sonraki bütün adımları etkileyen en kritik noktasında alınan bir hata yüzünden trilyonlarca meblağdaki işlem maalesef saatlerce yanlış işlendi. Fakat bunu farkettiğimizde işlemler çoktan veritabanına insert edilmişti bile. Insert edilmişti ama yanlış insert edilmişti, bu şekliyle hiçbir anlamları yoktu.
En başta alınan hata mesajı, fırlatılan exception ‘ın açıklaması aynen şu şekildeydi : “The conversion of a char data type to a datetime data type resulting in an out-of-range datetime value.” Yani, tablodaki DateTime tipindeki alana string tipte gönderilen tarih formatı kabul edilen bir formatta değildi. Uygulama ile Veritabanı aynı server üzerinde çalışıyordu. Buna rağmen uygulamanın datetime tipindeki değişkeni (diyelim ki a olsun ismi) a.ToString() ile alındığında ne hikmetse SQL in kabul ettiği formatı üretmiyordu. SQL Server üzerinden yaptığımız deneme üzerine anladık ki “yyyy-MM-dd” formatı kabul ediliyordu ancak “dd-MM-yyyy” formatı kabul edilmiyordu, sorunun bir kısmını tespit etmiştik. İyi de peki sebebi neydi??
İlk önce aklımıza gelen, uygulamanın çalıştığı server’ın “regional setting” i ile veritabanının “regional settings” i acaba uyuşuyor mu sorusu idi. Kontrollerimiz sonunda bir fark olmadığını gördük. İyice stres basmıştı. O sırada SQL Server Management Studio üzerinden login olduğumuz veritabanı serverının “Logins” listesini açtık, biraz da gayr-ı ihtiyari.. Daha sonra o listede bulunan kullanıcıların özelliklerini tek tek açıp, göz gezdiriyorduk. O an kafamda şimşekler çaktı karşılaştığım ekranlar sonrası..
Kontrol ettiğimiz 2 ayrı Login kullanıcısının “Default Language” property leri birbirinden farklı idi, biri Turkish seçili iken diğeri English olarak seçilmişti. English seçili olan ise bizim uygulamamız üzerinden login olduğumuz kullanıcı idi. “Yahu login olunan kullanıcının bu Default Language” property si acaba bu konuda etkili olurmu?” diye düşünüp bu soruyu yöneticim ile paylaştığımda “Evet” cevabını aldım ve hemen test etmek için önce English iken test ettik ve geerçekten de yukarıda bahsettiğim formatlardan ilkini kabul ederken, ikincisinde yukarıda not ettiğim exception ı fırlatıyordu. Daha sonrasında ise Turkish olarak güncelledikten sonra yine iki format için test ettik ve “OLEEYYY!!” işte iki format için de insert oluyordu..
İşte sorunun sebebi bu idi.. DB Server a Login olunan kullanıcı profillerinin Default Language property sine göre SQL Server ‘ın farklı kuralları yönettiğini bu şekilde anlamış olduk.. Hem de ağır bir bedelle, ciddi bir stres yüküyle.. Hem de karşı tarafın eksiği sebebiyle..
Başıma gelen bu durum, başkalarının da başına gelebilir diyerek paylaşmak istedim. Biraz hikaye gibi anlattım, belki karışık olmuştur. Aşağıya gerekli ekran görüntülerini ekliyorum, şimdilik bu kadar olsun 🙂