Mikro v16 ve v17 Farkları: SQL Sorgularınız Neden Bozulur, Nasıl Uyarlanır

Mikro'yu yeni sürüme yükselten birçok işletmenin ilk fark ettiği şey, eski raporlarının ya da SQL sorgularının artık hata vermesidir. Bunun nedeni basittir: v16 ve v17 aynı veritabanı değildir. Tablolar, kolonlar ve fonksiyon imzaları sürümler arasında değişebilir. Bu yazıda farkların neden sorgularınızı bozduğunu ve geçişte raporlarınızı nasıl kırılmadan koruyacağınızı anlatıyoruz.

Neden bir sürüm sorguyu bozar?

Bir SQL sorgusu, çalıştığı veritabanının şemasına birebir bağımlıdır. v16 için yazılmış bir sorgu şunlara güvenir:

• Belirli tablo adlarının var olduğuna,
• Belirli kolon adlarının (ve tiplerinin) var olduğuna,
• Bir fonksiyonun belirli parametreleri belirli sırayla aldığına.

Yeni sürümde bunlardan biri değişirse sorgu ya hata verir (kolon bulunamadı) ya da daha kötüsü, sessizce yanlış sonuç döndürür (anlamı değişmiş bir kolonu eskisi gibi yorumlar).

Tipik kırılma noktaları

Sürüm geçişlerinde en sık şu noktalar sorun çıkarır:

• Yeniden adlandırılmış kolonlar. Bir alan, yeni sürümde farklı bir adla gelebilir; eski ada referans veren sorgu "invalid column" hatası alır.
• Yeni eklenen alanlar ve varsayılanlar. Yeni zorunlu alanlar, eski INSERT/rapor mantığını etkileyebilir.
• Değişen fonksiyon imzaları. fn_ fonksiyonları yeni parametre isteyebilir ya da parametre sırası değişebilir.
• Anlamı değişen kodlar. Bir tip/durum kolonundaki sayısal kodların karşılığı sürümle farklılaşabilir.
• Birleşen/ayrılan tablolar. Bazı veriler farklı tablolara taşınmış olabilir.

"Çalışıyor" yanılgısı

En tehlikeli durum, sorgunun hata vermeden çalışıp yanlış sonuç üretmesidir. Örneğin bir durum kodunun anlamı değiştiyse, eski sorgu hâlâ çalışır ama iptal kayıtlarını satış gibi sayabilir. Rapor çıkar, sayı görünür, kimse fark etmez — ta ki mizan tutmayana kadar. Bu yüzden sürüm geçişinden sonra kritik raporların doğrulanması şarttır.

Raporlarınızı kırılmadan uyarlamak

Sürümler arası geçişte sağlıklı bir yol haritası:

1. Kritik raporları listeleyin. Cari ekstre, mizan, stok değeri, satış özeti gibi karar verdiren raporlar önceliklidir.
2. Şema farklarını çıkarın. Hangi tablo/kolon/fonksiyon değişti? Bunu bilmek, hangi sorguların etkileneceğini gösterir.
3. Sonuçları eski sürümle karşılaştırın. Aynı tarih aralığında v16 ve v17 sonuçları tutuyor mu? Tutmuyorsa fark nereden geliyor?
4. Tek kaynaktan üretin. Sorguları sürüm-farkında bir araçla üretmek, her sürüm için ayrı ayrı elle bakım yapma yükünü ortadan kaldırır.

Sürüm-farkında SQL üretmenin avantajı

Erp Asistanı'nda sürüm, sorunun bir parçasıdır. SQL üretirken v16 mı v17 mi olduğunu seçersiniz (ya da bağlantınızdan otomatik algılanır) ve:

• Sorgu, o sürümün gerçek tablo ve kolonlarına göre kurulur,
• Olmayan ya da yeniden adlandırılmış kolonlar kullanılmaz,
• Fonksiyonlar o sürümün beklediği imzayla çağrılır,
• Aynı soruyu iki sürüm için sorup sonuçları karşılaştırabilirsiniz.

Böylece "v16'da çalışan sorgu v17'de patladı" sorunu kaynağında çözülür: her sürüm için doğru sorgu, baştan üretilir.

Sık sorulanlar

v16 sorgum v17'de neden hata veriyor? Büyük olasılıkla bir kolon/tablo adı değişti ya da bir fonksiyon imzası farklılaştı. Sorguyu v17 şemasına göre yeniden üretmek en güvenli çözümdür.

Hangi sürümde olduğumu nasıl anlarım? Bağlantı üzerinden otomatik tespit edilebilir; kullanıcıya ayrıca sorulması gerekmez.

İki sürümü aynı anda kullanıyorum, ne yapmalıyım? Her sorguyu ilgili sürüm için ayrı üretin. Tek bir sorgunun iki sürümde de "aynı" çalışacağını varsaymayın.

Sürüm yükseltmek raporlarınızı kaybetmek anlamına gelmez. Doğru sürümü seçin, sorgunuzu o sürüme göre üretin; geçiş sancısız olsun.

Sürümünüzü seçip SQL üretin →