Neden ikinci bir veritabanı bağlantısına ihtiyaç duyarsınız

Normal şartlarda TROIA'da veritabanı bağlantısı oturumun (session) bir özelliğidir — login olduğunuzda sistem, biri SELECT/UPDATE/INSERT/DELETE gibi tüm SQL işlemleri için, diğeri interpreter seviyesindeki loglama gibi arka plan görevleri için olmak üzere aynı veritabanına iki bağlantı açar. Ama bazen tek veritabanı yetmez: örneğin ana ERP veritabanından bağımsız, ayrı bir raporlama veritabanına ya da başka bir CANIAS ortamının veritabanına okuma yapmanız gerekebilir. İşte MAKENEWCONNECTION tam olarak bunun için var.

Bağlantı açma, aktif etme ve kapatma

MAKENEWCONNECTION {baglantiadi} {kullanici} {sifre} {dbsunucu} {dbadi};
SETACTIVECONNECTION {baglantiadi};
SETACTIVECONNECTION DEFAULT;
CLOSECONNECTION {baglantiadi};

Burada dikkat edilmesi gereken şaşırtıcı bir detay var: {kullanici} ve {sifre} parametreleri tamamen yok sayılır, sadece geriye dönük uyumluluk için duruyor. Gerçek kimlik bilgileri {dbsunucu} ve {dbadi} parametrelerinin karşılık geldiği sunucu konfigürasyon dosyasındaki tanımdan geliyor. Yani bu komutu ilk gördüğünüzde "şifreyi buraya mı yazacağım" diye düşünüyorsanız, cevap hayır — asıl ayar sunucu tarafında.

SETACTIVECONNECTION'ın kapsamı: oturum, tek transaction değil

Belgelerdeki en kritik uyarı şu: aktif bağlantıyı değiştirdiğinizde, bu değişiklik o oturumdaki halihazırda açık olan transaction'lar da dahil tüm transaction'ları etkiler. Yani SETACTIVECONNECTION çağırdığınız an, sadece o an çalışan kod değil, aynı oturumdaki diğer açık transaction'lar da yeni bağlantıyı kullanmaya başlar. Bu, çok transaction'lı bir akışta beklenmedik davranışlara yol açabilir — bir transaction'da veritabanı değiştirip işinizi bitirdikten sonra SETACTIVECONNECTION DEFAULT; ile eski bağlantıya dönmeyi unutmak, sonraki kodun yanlış veritabanına yazmasına neden olabilir.

Transaction komutları aktif bağlantıya göre çalışır

BEGINTRAN, COMMITTRAN, ROLLBACKTRAN gibi transaction komutları ve SYS_INDBTRANSACTION sistem değişkeni, her zaman o anki aktif bağlantı üzerinde işlem yapar. Aktif bağlantıyı değiştirdiğinizde, bu komutların hedefi de otomatik olarak değişir.

Gerçek bir örnek: raporlama veritabanından okuyup ana veritabanına yazmak

/* Raporlama veritabanından özet veri okuyup ana veritabanındaki tabloya işler. */
LOCAL:
    TABLE OZET(URUNKODU CHAR(20), TOPLAM DECIMAL);

MAKENEWCONNECTION 'RAPORDB' '' '' 'RAPOR_SUNUCU' 'RaporlamaDb';

IF SYS_STATUS = 1 THEN
    MESSAGE 'Raporlama veritabanına bağlanılamadı.' TYPE ERROR;
    RETURN;
ENDIF;

SETACTIVECONNECTION 'RAPORDB';

SELECT URUNKODU, TOPLAM FROM AYLIK_OZET INTO OZET;

SETACTIVECONNECTION DEFAULT;
CLOSECONNECTION 'RAPORDB';

/* Buradan itibaren kod tekrar ana (varsayılan) veritabanı üzerinde çalışır. */
LOOP AT OZET;
    /* ... ana veritabanındaki ilgili tabloya INSERT/UPDATE ... */
ENDLOOP;

Dikkat edin: SETACTIVECONNECTION DEFAULT ve CLOSECONNECTION çağrısını, ihtiyaç duyduğunuz veriyi okur okumaz yaptım — bağlantıyı gereğinden uzun süre açık/aktif bırakmamak, hem kaynak tüketimini azaltır hem de az önce bahsettiğim "yanlış bağlantı üzerinde işlem yapma" riskini ortadan kaldırır.

Sık yapılan hatalar

  • SETACTIVECONNECTION DEFAULT çağırmayı unutmak — kod bir hata ile erken RETURN ederse aktif bağlantı ikincil veritabanında kalmış olabilir; sonraki kodun (özellikle aynı oturumda çalışan başka bir transaction'ın) sessizce yanlış veritabanına yazması, teşhisi en zor hata sınıflarından biridir. Hata durumlarını da kapsayacak şekilde bağlantıyı eski haline döndürmeyi garanti altına alın.
  • Bağlantıyı kapatmayı unutmak — CLOSECONNECTION çağrılmazsa bağlantı oturum sonuna kadar açık kalabilir; çok sayıda kullanıcı aynı anda ikincil veritabanına bağlanıyorsa bu, hedef veritabanı sunucusunda bağlantı limitine takılmaya yol açabilir.
  • Dedicated bağlantıyı gereksiz yere kullanmak — belgeler, kaynak paylaşımını azaltmak için multithreading gibi özel senaryolarda "dedicated" veritabanı bağlantısı açılabileceğini ama bunun genel kullanım için önerilmediğini açıkça belirtiyor; normal iş akışlarında paylaşımlı bağlantı modelinden ayrılmak için gerçek bir teknik gerekçeniz olmalı.
  • Kimlik bilgilerinin komuttan geldiğini sanmak — yukarıda belirttiğim gibi kullanıcı/şifre parametreleri yok sayılıyor; erişim sorunlarını "koddaki şifre yanlış" diye aramak yerine doğrudan sunucu config dosyasındaki bağlantı tanımını kontrol etmek gerekiyor.

Sıradaki adım

Bir sonraki yazıda SELECT ... INTO ile temel veri okuma ve büyük sonuç kümelerinde performansı etkileyen faktörlere değineceğim.