Cari hesapta Satır Satır Bakiyeyi çıkarmak

[pcman]

Arkadaşlar merhaba,

Ek'teki örnekte bir cari hesap tablosu var,

Sorgu1 de deki bakiye kısmınına bakiyeyi nasıl yazdırabilirim,

id lere göre olması gereken bakiyeler aşağıdaki gibidir,

id=1, Bakiye= -1000
id=2, Bakiye= -3000
id=3, bakiye= -2500

yardımlarınız için teşekkürler,

 

[Taruz]

Merhaba..

Bu sorgu istediğiniz değerleri verir..

SELECT pcman.id, pcman.Tarih, pcman.Aciklama, pcman.Borc, pcman.Alacak, 
(select sum([alacak]-[borc]) from cari where  id<=pcman.id) AS Cari
FROM cari AS pcman

 

[pcman]

Sn Taruz, Teşşkürler,

Bir önceki veriyi okuyarak bakiyeyi hesaplamışsınız, burda id=2 silip aynı tarihe farklı bir kayıt girdiğinde girilen kayıt son id alacak ve cari yanlış işleyecektir,

ben de sizinle aynı çözümü geliştirdim ilk önce tarihleri sonra id leri sorgulayarak bir önceki veriyi okuyup cariyi hesapladım,

ama bu yöntem veri arttıkça ağırlaşıyor, farklı bir yöntem olabilir mi?

 

[pcman]

şimdide aynı tarihte caride aynı veriyor...

 

[yeni54]

merhaba,
içteki select te id şartı olmamalı.
hız konusuna gelince, bu aşamada tarih için index yaratılması yeterli görünüyor.

 

[pcman]

şuan aynı tarihte aynı bakiyeyi alıyorum?

 

[Taruz]

Merhaba..

Siz id alanını şart olarak belirttiğiniz için bende yeterli gördüm. Sayın yeni54 ün yazdığı gibi tarih alanı kafi gelir olur bu hesaplama için.

Ben bu yöntemi 5000 kayıtlı bir dökümde kullanıyorum gayet hızlı.

 

[yeni54]

pcman, demek istediğini anladım ama çözüm bulamadım.
aradan bir kayıt silinip aynı kayıt yeniden kayıt yapıldığında, id alanı büyük olacağı için şaşırıyor.

sanki, silinen kayıtlar için ara bir eşleme tablosu tutulmalı gibi geldi bana.
bu tabloda hem ana tablodaki id olacak hem de silinen id ye karşılık gelen id.

yani, id ler 1 2 3 4 5 6 ... gibi gidiyor diyelim.
eşleme tablosunda (2 alanlı tablo. id ve esleme_id alanları olacak) görüntü
1 1
2 2
3 3
4 4
5 5
.....
şeklinde olacak.
diyelimki id si 3 olan kayıt silindi. ve 6 numara ile yeniden kayıt yapıldı.
o zaman esleme tablosu
6 3
olacak.
biraz karışık oldu. tam vakit ayıramadığım için derli toplu anlatamadım.

 

[Veysi Emrah]

Ben de benzer bir sorunla uğraşıyorum bu sebeple konu benimde ilgimi cekti. Oncelikle kendi sorumu sorayım. ikinci örnek tablodaki sorguda şu kod var;
select (sum([alacak]-[borc]) from cari...... diye gidiyor. Bu kodda "cari" neyi gösteriyor. Tablo olan "cari" mi yoksa sorgudaki "cari" sütununumu? Birde mümkünse kodun işlevini biraz açıklayabilirmisiniz.

İkinci olarak pcman'in verdigi 2'nci tabloda sanırım bir hata var sorguyu açtığımızda karşımıza gelen ekranda şunlar var

Tarih id Aciklama Borc Alacak Cari
01.01.2009 1 deneme 1000 0 -1000
09.01.2009 5 deneme5 100 0 -1100
10.01.2009 2 deneme2 2000 0 -3000
15.01.2009 3 deneme3 0 500 -2500
20.01.2009 4 deneme4 0 300 -2200
20.01.2009 6 deneme6 0 100 -2200

3'ncü sırada Cari değerinin 3100 olması gerekmezmi.
Sanırım kriter olarak id ve tarih dışında sırası şaşmayacak bir sütun daha lazım.

 

[pcman]

sorgu her çalıştığında kayıtlara artan bir id verebilirmiyiz?

rapor için metin kutusuna =1 yazarak bir id oluşturabiliniyor,
formda bir modüllü yapılıyor,

 

[Taruz]

SELECT pcman.Tarih, pcman.id, pcman.Aciklama, pcman.Borc, pcman.Alacak, 
(select count(*) from cari where  id<=pcman.id) AS Cari
FROM cari AS pcman
GROUP BY pcman.Tarih, pcman.id, pcman.Aciklama, pcman.Borc, pcman.Alacak
ORDER BY pcman.Tarih, pcman.id

Bunu deneyin..

 

[pcman]

Sn taruz,
verdiğiniz sorguyu denedim, id alanıyla aynı değer oluştu?

 

[yeni54]

1. mesajını tekrar okudum da,
id ye göre bakiye ne demek?
istenen tam olarak ne?
sanki yanlış birşeyin peşindeymişsin izlenimine kapıldım.

 

[pcman]

Sn Yeni54,

Konu biraz dağıldı, ben size özetleyeyim,

Tam olarak istediğim, muhasebe programlarında olduğu gibi cari dökümde, tarihli harekette bakiyeyi yazdırmak,

bir önceki satırın tarihini veya id sini okuyarak bakiyeyi hesaplattığımızda, eski bir tarihli kayıt silinip yeni bir id ile eski bir tarihe tekrar girildiğinde bakiye yanlış hesaplanıyor,

ozaman hazırlayacağımız sorguyu ilk önce tarih sonra id sıralaması yaptığımızda istediğimiz düzeni sağlıyoruz, bu sorguda herçalıştığında 1 den başlayarak ayrı bir id kolonu oluşturabilirsek bir önceki veriyi okuyarak bakiyeyi hesaplayabiliriz,

yardımlarınız için teşekkür ederim,

 

[Taruz]

Merhaba..

Aslında başından beridir son yazdıklarınızla ilgili örnekler verdim. Aradan bir kaydın ve dolayısıyla id alanının silinmesi önemli değil. Burada geçerli olan eğer birden fazla firma da varsa, sorgu önce firmaya bakar, sonra tarihe ve en sonda id ye bakar aynı tarihte birden fazla hareket olursa id ye göre bakiyeyi devir verir..

Bu durumda ilk verdiğim örneğin alt sorgusuna tarihin eşit ve küçük koşulu ve varsa firma-isim alanın eşit olma koşulu ilave edilerek istediğiniz değerleri verir..

Yanlışsam sayın yeni54 düzeltsin..

Sn taruz,
verdiğiniz sorguyu denedim, id alanıyla aynı değer oluştu?

id ardışıksa aynı değerleri görmeniz normal.. Aradan bir kayıt silince sıralamayı daha iyi göreceksiniz.. İstediğiniz işlem için buna gerek yok ama..

Selamlar..

 

[pcman]

Sn Taruz, Sn yeni54,

yardımlarınız için teşekkür ederim,

Sn Taruz,
farklı bir firma yok, ilk önce tarih alanını sonra id olanını küçük ve eşit yaptığımızda aynı tarihtaki satırlarda bakiye yanlış hesaplanıyor, nedenini anlamadım,

Ben yardımlarınızla aşağıdaki gibi bir çözüm geliştirdim,

sorgu adında bir sorgu hazırladım,

SELECT Mid(cari!Tarih,1,2) & Mid(cari!Tarih,4,2) & Mid(cari!Tarih,9,2) & cari!id AS Sira, cari.Tarih, cari.id, cari.Aciklama, cari.Borc, cari.Alacak
FROM cari
GROUP BY Mid(cari!Tarih,1,2) & Mid(cari!Tarih,4,2) & Mid(cari!Tarih,9,2) & cari!id, cari.Tarih, cari.id, cari.Aciklama, cari.Borc, cari.Alacak
ORDER BY Mid(cari!Tarih,1,2) & Mid(cari!Tarih,4,2) & Mid(cari!Tarih,9,2) & cari!id;

sıra alanın da gün, ay, yil ve id alanlarıyla bir referans oluşturdum,

sorgu1 sorgusunda bakiyeyi hesapladım, ve sorgu sorgusundaki sıraya eşit küçük koşulunu koydum,

SELECT pcman.Sira, pcman.Tarih, pcman.id, pcman.Borc, pcman.Aciklama, pcman.Alacak, (select sum([alacak]-[borc]) from sorgu where   sira<=pcman.sira) AS Cari
FROM Sorgu AS pcman
GROUP BY pcman.Sira, pcman.Tarih, pcman.id, pcman.Borc, pcman.Aciklama, pcman.Alacak;

şuan eski bir kayıt silinip tekrar eski bir tarihe girilsede sıra alanında gün, ay, yil ve id ile bir referas oluşacağı için bir problem olmuyor,

sizden ricam bu yöntemi 5000 kayıt civarındaki kendi sorgunuzda deneyip performansını kontrol etmeniz,

Geri bildirimlerinizi rica ediyorum,

 

[Taruz]

Merhaba..

Sorununuz önceki tarihli işlemi sonradan yazdığınızdan kaynaklanıyor.. Uyguladığınız yöntem akıllca olmuş..

 (select sum([alacak]-[borc]) from sorgu where  tarih&id<=pcman.tarih&pcman.id )

Bu şekilde de oluşturulabilir..

Şimdi sizin için en iyi performansı hangisi verir onu ölçelim.. Birazdan geliyorum..

 

[pcman]

Sn Taruz,

iltifatınız için teşekkürler,

eski tarihli bir kaydı silip daha sonradan tekrar girmek olabilecek birşey diye düşünüyorum, bu detay olmasa verdiğiniz sorgu gayet iyi çalışıyordu,

 

[Taruz]

Merhaba..

Sizin uyguladığınız sistemle benim son önerdiğim şekilde hazırladığım iki sorguyu 5000 kayıtla 10 kez çalışrıtıp her sorgunun açılış süresinin ortalamasını karşılaştırdım. İlk sorgu ortalama 3,4469 saniyede, ikincisi ise 1,8766 saniyede açılıyor..

Yapınızı buna göre oluşturmanızı öneriyorum. Bir önerim de, bu tür çok verili sorgularda olabildiğince sıralama yani order by kısmını kullanmaktan kaçınmanız. Performansta çok etki ediyor.

İkinci sorgunun tamamı şu şekilde..:

SELECT pcman.Tarih, pcman.id, pcman.Borc, pcman.Aciklama, pcman.Alacak, 
(select sum([alacak]-[borc]) from sorgu where  tarih&id<=pcman.tarih&pcman.id ) AS Cari
FROM Sorgu AS pcman

Bunu kullancaksınız Sorgu ismli kaynaktan sira alanını kaldırınki açılma süresini etkilemesin..

 

[pcman]

Sn Taruz,

Tamamdır, bence bu yöntem cari hesap çalıştıracak herkesin işine yarıyacaktır,

teşekkütler,