firebird Ems Sql Manager ile Borc Alacak Bakiye

[akuyumcu63]

Merhaba;
paradox veri tabanından firebirde terfi ettim. daha önce yazmış olduğum programlarımı firebirdde yazmaya çalışıyorum.
borç alacak bakiye (artan bakiye) olayını bir kaç gündür formda araştırıyorum. bir çok kod örnekleri var muhtemelen bu kod örnekleri istenen sonuçları veriyordur.
benim sorunum bu kod örneklerini nerede nasıl deneyeceğim hakkındadır. Tablo ve alanların aşağıdaki gibidir.

TBLCARIKAYIT (ID,CARIKOD,ADISOYADI) alanlarından oluşmaktadır,
TBLCARIHAREKET(ID,CARIID,HAREKETKOD,TARIH,ACIKLAMA,BORC,ALACAK) alanlarından oluşmaktadır.

EMS SQL Manager kullanıyorum. BAKIYE yi Hesaplanmış alan kullanarak mı, Stored Procedur ile mi , triger ile mi, View ile mi, hangisi ile yapmalıyım, veriler çoğaldığında da sorun çıkarmamalı,

dediğim gibi bu işlem için formda bir çok kod örneği var. kodları nasıl kullanacağım hakkında yardımcı olabilirseniz memnun olurum.
eğer örnek döküman varsa mail adresim (akuyumcu63@hotmail.com) adresine gönderebilirsiniz. şimdiden teşekkür ederim.

[esistem]

Merhaba; bende tam bu konu hakkında soru sormak için girmiştim foruma. Ben kendi çözümümü (alıntıdır) yazayım ve sorumuda sorayım.
İlk olarak cari hareket tablosuna bakiye adında bir alan tanımlayıp tabloya her girip çıkan kayıttan sonra hesaplayan procedure ile çözmüştüm olayı fakat kayıt çoğalınca yavaşlama olucaktır (ki oluyor) düşüncesi ile bunu değiştirmeyi düşünüyordum ki bir kaç gün önce boreas ın günlüğü diye bir site ile karşılaştım (kendisine burdan çok teşekkür ederim) ve çözümü orda buldum sizede yazayım,
Öncelikle cari hakeket tablomu QISLEM adlı query ile çağırıyorum, QISLEM master-detail ile QCARI tabloma bağlı, bir tane de yine CARI tablosuna (SOURCE) bağlı QSIFIRLA adında query im var, QSIFIRLA sql kodu : SELECT rdb$set_context( 'USER_TRANSACTION' ,'bakiye#' ,0) from rdb$database;
şeklinde firebird veritabanında kullanıcı tanımlı bakiye adında bir alan oluşturup değerini sıfıra eşitliyor,
QISLEM tablosunun sql kodu ise :

Kod: Tümünü seç

SELECT KOD, CARIKODU, ISLEMTURU, ISLEMKODU, TARIH, BORC, ALACAK, BAKIYE, ACIKLAMA, BAYIKODU,
CASE
WHEN ISLEMTURU=0 THEN  'Devir Borç'
WHEN ISLEMTURU=1 THEN  'Devir Alacak'
WHEN ISLEMTURU=2 THEN  'Satış Fat.'
WHEN ISLEMTURU=3 THEN  'Alış Fat.'
WHEN ISLEMTURU=4 THEN  'Nakit Tahsilat'
WHEN ISLEMTURU=5 THEN  'Nakit Ödeme'
WHEN ISLEMTURU=6 THEN  'Çek Giriş Bordrosu'
WHEN ISLEMTURU=7 THEN  'Çek Çıkış Bordrosu'
WHEN ISLEMTURU=8 THEN  'Senet Giriş Bordrosu'
WHEN ISLEMTURU=9 THEN  'Senet Çıkış Bordrosu'
WHEN ISLEMTURU=10 THEN  'Kredi Kartı Tahsilatı'
WHEN ISLEMTURU=11 THEN  'Kredi Kartı Ödemesi'
WHEN ISLEMTURU=12 THEN  'Banka Yoluyla Tahsilat'
WHEN ISLEMTURU=13 THEN  'Banka Yoluyla Ödeme'
WHEN ISLEMTURU=14 THEN  'Borç'
WHEN ISLEMTURU=15 THEN  'Alacak'
END AS ISLEMADI,
coalesce(CAST(rdb$get_context('USER_TRANSACTION','bakiye#' ) AS decimal(10,4) ),0) as tbakiye,
CAST(rdb$set_context('USER_TRANSACTION','bakiye#',coalesce(CAST(rdb$get_context('USER_TRANSACTION','bakiye#' )AS decimal(10,4) ),0)+ BORC - ALACAK )AS decimal(10,2) )as Set_Bakiye
FROM CARI_ISLEM WHERE CARIKODU =:KOD AND TARIH>=:T1 AND TARIH<=:T2
ORDER BY TARIH, KOD

şeklinde, yani cari hesaplarda her hareket edildiğinde önce kullanıcı tanımlı değişken oluşturulup 0'a eşitleniyor ardından da QISLEM sorgusunda her satırdaki bakiye hesaplanıyor. Kısaca yöntem bu ve çok kolay.

Benim sormak istediğim ise bu kullanıcı tanımlı değişken olayı sağlıklı olurmu veya hızda bir problem yaratırmı ? bilen arkadaşların düşüncelerini bekliyorum.

[akuyumcu63]

merhaba;
kaç gündür bu konu ile ilgili bir yorum bekliyordum. ilginiz için öncelikle teşekkür ederim. verdiğiniz örneği projemde deneyeceğim sonucu buraya yazarım. sorunuza gelince bir şey diyemem daha bilgili ve tecrübeli arkadaşların yorumunu birlikte beklememiz gerek.

[volkancesur]

Bu İşlemin Trigger İle yapılması mümkün mü peki ?