fb vt ye kayıt girme yöntemi hakkıda

[meron06]

sel.al.arkadaşlar.az önce soruyu yazdım forumda görüntülenmedi.refresh de yaptım ama nedense bilmiyorum artık.

sormak istediğim şey.firebird 1.5 delphi 7 kullanıyorum.ibquery,ibdatabase,ibupdatesql,transaction ,datasource bileleşenleri ni kullanarak yeni kayıt silem düzenleme yapıyorum.
yeni kayıt girerken şu yöntemi kullanıyorum

ibqueery.appen;
ibquery.fieldbyname('alan adı').value:=değer;
ibquery.post;
ibtransction.commitreatenin;

şimdi burda sormak istediğim bu yöntem doğrumu .yoksa kayıtları insert metodunu kullanarak sp ilemi yapmak lazım. hangisi daha iyi dir.

[Ali Erdoğan]

Splerle kayıt almak bütün veri tabanları için tavsiye edilen bir durumdur. Spler derlendiği için çok daha hızlı çalışır. Hemde ağ üzerinde koca bir sql cümlesi yerine sadece parametreler iletileceği için sp ler daha performanslıdır. Ancak splerle kayıt yapmak elbetteki daha zahmetlidir. Aşırı performans gerektiren uygulamalar haricinde çok fazla uğraşmana gerek yok spler ile.

Bu arada commitretaining dediğinde, senin kontrolün dışında bir durum gerçekleştiğinde eklenmiş veya değiştirilmiş veriler geri alınır. Buda önemli veri kayıpları oluşabileceği demek. Bu yüzden istisna durumlar haricinde commit kullanman daha iyidir.

[meron06]

Ali kardeş .şimdi forumda hep konuşuluyor commitreatening .kullanılmalı diye.bende hep kullanıyorum.bi yanlışa duşmeyelim.biraz açıklayabilirmisin bu olayı.

[Terminator]

SP ile kayıt nedir bre?
evet gayet güzel insert etmişsin, parametrik query ve insertin servera maliyeti gayet düşük. datasetin çok şişkinse bu işlemin client side olarak yavaşlayacaktır, yani bu teknikle bulk insert yapılmaz.

commitretainingin committen farkı serverin transactionı onaylayıp yeni bir numaraya geçmesi ama bunu eldeki işlemleri kapatmadan, sanki transaction devam ediyormuş gibi yapmasıdır. yani transaction seviyesinde bir savepoint gibi çalışır. yapılan işlemlerin elde tutulması
ve devamı sizin yaptığınız iş için lazım değilse bu durum tabi ki servera gereksiz bir yük bindirecektir. düşünün günlerce hard commit edilmemiş bir sistem elindeki açık bütün cursorları vs bellekte yaşatmak zorunda.
3-5 kullanıcının üstünde sistem geliştirmemiş, çok kullacılı sistemlerde eğitim almamış geliştiriciler için bunu farketmek zor olacaktır.
Eğer elinizdeki datasetler size lazımsa, ama yaptığınız işleri de onaylamak istiyorsanız commitretaining bunun çözümüdür. tabi okuma ve yazma transactionlarını ayrı kullanmak da profesyonelce bir çözüm..
BDE, dataları kaybetmeden sürekli autocommit şekilde retaining sayesinde çalışabiliyordu. Ama BDE bu yüzden yavaştı diyenler bi adım öne çıksın, ceza vericem!

[aLonE CoDeR]

Bu arada commitretaining dediğinde, senin kontrolün dışında bir durum gerçekleştiğinde eklenmiş veya değiştirilmiş veriler geri alınır.

Şimdi bi saniye;

Kontrol dışı bir işlem gerçekleşmesinden kasıt nedir burda, değişikliğin ya da insert'in geri alınmasını gerektirecek ya da daha farklı bi senaryo olarak düşündüğümüzde bu nasıl bir işlemdir anlamadım bunu...

[Ali Erdoğan]

Kontrol dışı bir işlem gerçekleşmesinden kasıt nedir burda, değişikliğin ya da insert'in geri alınmasını gerektirecek ya da daha farklı bi senaryo olarak düşündüğümüzde bu nasıl bir işlemdir anlamadım bunu...

Daha önce başıma çok işler açıldı bu commitretaining yüzünden. Gecenin bi vakti iş yerinden arıyorlardı. Bir satış sisteminde kredi kartı pos makinesinden alınan z raporu ile programdan alınan z raporu arasında fark var diye.

Gittim, saatlerce beraber satış yaptık bir türlü sorun göremiyordum. En son bir satış yaparken satışları işledi, ve gözüken miktarı tahsil etti. Ancak satışı kapat dediğinde en son commitretaining de eklenenler geri alındı ve son satılan ürünler iptal edilerek kaydedilmiş oldu. Sorunu commitretaining yerine commit kullanarak çözdüm ve 6-7 aydır bir sorun gözükmüyor.

Bilmiyourum belkide ibx bileşenlerinin bir bug ı olabilir. Ama dediğim gibi commitrtaining de bazen kontrol dışı rollback ler gerçekleşebiliyor.

[Terminator]

Kontrol dışı bir işlem gerçekleşmesinden kasıt nedir burda, değişikliğin ya da insert'in geri alınmasını gerektirecek ya da daha farklı bi senaryo olarak düşündüğümüzde bu nasıl bir işlemdir anlamadım bunu...

Daha önce başıma çok işler açıldı bu commitretaining yüzünden. Gecenin bi vakti iş yerinden arıyorlardı. Bir satış sisteminde kredi kartı pos makinesinden alınan z raporu ile programdan alınan z raporu arasında fark var diye.

Gittim, saatlerce beraber satış yaptık bir türlü sorun göremiyordum. En son bir satış yaparken satışları işledi, ve gözüken miktarı tahsil etti. Ancak satışı kapat dediğinde en son commitretaining de eklenenler geri alındı ve son satılan ürünler iptal edilerek kaydedilmiş oldu. Sorunu commitretaining yerine commit kullanarak çözdüm ve 6-7 aydır bir sorun gözükmüyor.

Bilmiyourum belkide ibx bileşenlerinin bir bug ı olabilir. Ama dediğim gibi commitrtaining de bazen kontrol dışı rollback ler gerçekleşebiliyor.

kontrol dışı rollback diye bişey olmaz.
sen yaptığın commit, commitretaining, rollback işlemlerinden sonra
işlemin sonucunu handle ediyor musun? okey alıyor musun?
bunu kullanıcıya duyuruyor musun? hangi OS, IB versiyonunu kullanıyordun bu sorunu aldığın dönemde?

bir kere zaten commit yapılmadan ve success alınmadan satış tamamlanmış olmaz. yani kayıtlar resmileşince tahsilat yapılır, bunun resmi süreci budur. elle faturalama, müşteriye özel işletmelerdeki özel uygulamalar bu kuralı bağlamaz.

[Ali Erdoğan]

Kontrol dışı bir işlem gerçekleşmesinden kasıt nedir burda, değişikliğin ya da insert'in geri alınmasını gerektirecek ya da daha farklı bi senaryo olarak düşündüğümüzde bu nasıl bir işlemdir anlamadım bunu...

Daha önce başıma çok işler açıldı bu commitretaining yüzünden. Gecenin bi vakti iş yerinden arıyorlardı. Bir satış sisteminde kredi kartı pos makinesinden alınan z raporu ile programdan alınan z raporu arasında fark var diye.

Gittim, saatlerce beraber satış yaptık bir türlü sorun göremiyordum. En son bir satış yaparken satışları işledi, ve gözüken miktarı tahsil etti. Ancak satışı kapat dediğinde en son commitretaining de eklenenler geri alındı ve son satılan ürünler iptal edilerek kaydedilmiş oldu. Sorunu commitretaining yerine commit kullanarak çözdüm ve 6-7 aydır bir sorun gözükmüyor.

Bilmiyourum belkide ibx bileşenlerinin bir bug ı olabilir. Ama dediğim gibi commitrtaining de bazen kontrol dışı rollback ler gerçekleşebiliyor.

kontrol dışı rollback diye bişey olmaz.
sen yaptığın commit, commitretaining, rollback işlemlerinden sonra
işlemin sonucunu handle ediyor musun? okey alıyor musun?
bunu kullanıcıya duyuruyor musun? hangi OS, IB versiyonunu kullanıyordun bu sorunu aldığın dönemde?

bir kere zaten commit yapılmadan ve success alınmadan satış tamamlanmış olmaz. yani kayıtlar resmileşince tahsilat yapılır, bunun resmi süreci budur. elle faturalama, müşteriye özel işletmelerdeki özel uygulamalar bu kuralı bağlamaz.

Sistem WinXp Firebird 1,5...

Sistem şöyle işliyor. Bir satış işlemi için satışlar tablosundan bir satır açıyorum. Daha sonra bu satırla ilişkili olarak ürünler giriliyor ve ürün girildikçe commitretaining yapılıp toplam satış fiyatı kullanıcının karşısında doğru bir şekilde yazıyor. Aynı anda birden çok açık satış işlemi var ve eğer kullanıcı son ekleme yaptığı satış kaydına kapat derse (kapatma işlemi tahsilattan sonra oluyor) son satılan ürün commitretaing yapıldığı halde geri alınıyor. İşin tuhaf tarafı bu herzaman olmuyor. 20- 30 kayıtta bir böyle bir tuhaflık gerçekleşiyor.

Başka hiçbir kod değişikliği yapmaksızın sadece commitretainig yerine commit kullanarak problemi çözdüm.

[Terminator]

Sistem WinXp Firebird 1,5...

Sistem şöyle işliyor. Bir satış işlemi için satışlar tablosundan bir satır açıyorum. Daha sonra bu satırla ilişkili olarak ürünler giriliyor ve ürün girildikçe commitretaining yapılıp toplam satış fiyatı kullanıcının karşısında doğru bir şekilde yazıyor. Aynı anda birden çok açık satış işlemi var ve eğer kullanıcı son ekleme yaptığı satış kaydına kapat derse (kapatma işlemi tahsilattan sonra oluyor) son satılan ürün commitretaing yapıldığı halde geri alınıyor. İşin tuhaf tarafı bu herzaman olmuyor. 20- 30 kayıtta bir böyle bir tuhaflık gerçekleşiyor.

Başka hiçbir kod değişikliği yapmaksızın sadece commitretainig yerine commit kullanarak problemi çözdüm.

tabloda satır açılmaz, satır ekran grid kompenentinde açılır.
her commit retainingden sonra işlem sonucunun başarısını kontrol ettin mi?
commit demek illa commit edilecek demek değildir!
commit bir istektir, onaylanır ya da hata alınır, alınan hataya göre ya duruma uygun düzeltme yapılıp tekrar commit denir ya da herşey uçar gider.. commit edilip edilmediğini hem dönüş kodundan hem de
yeni alınan transaction numara farkından anlayabilirsiniz.

sadece commit demenle aynı işlem bitmiş olamaz.
commitretainig yerine commit kullanabilmen için tüm datasetlerini sürekli
yeniden açıp herşeyi ayarlaman gerekir.
commit, transactionla beraber bütün dataları kapatır,
datalar kapatılınca bunu kullanan compenentler de boşaltılır.
yani, yeniden transaction başlatıp hepsini
yeniden gerekli bilgilerle doldurmadan nasıl yaptın bu işi?
commitretainingin bazen commit başarılı olduğu halde geri aldığını ilk kez senden duyuyorum. FBün bir transactioni tamam yaptım dediği halde geri alması imkansız bi durum.
ancak forced write olmadığı için sayfalar uçarsa belki bazı kayıtlar gidebilir, ama sen dosya bozulmasından da bahsetmiyorsun.

[freeman35]

ben de anlamadım açıkçası, try except e aldığın bir kod varsa ve except e bir şey yazmadıysan hata verir ama program kırılmaz.
kullandığın grid e bağlı olarak, eğer satır post edilmeden, bir buttona basarsan grid in OnExit i tetiklenir ve bu bazı gridlerde (cxgrid vs) default CancelOnExit := True; olduğundan veri post edilmez.
Birde aklıma gelen olasılık Transaction ın TimeOut options ı default rollback tir. Tabi bu kullandığın component a göre değişir.
FireBird ün ruh haline göre işlem yapma ihtimali bence imkansızın karesi hatta kübü

Kolay gele

[Ali Erdoğan]

Kod: Tümünü seç

procedure TfrmStSatisBirimi.UrunSat;
begin

  if dtsSATISlar.IsEmpty then
    begin
      MessageDialog.ShowModal;
      exit;
    end;
  satti := true;
  with dtsSATISUrunler do
    begin
      Active := true;
      if Locate('SATISURUNSTOKID', Srgurunler.fieldbyname('STOKID').AsInteger, 

[loCaseInsensitive]) = false then
        begin
          Append;
          edit;
          FieldByName('SATISID').AsInteger := dtsSATISlar.fieldbyname('SATISID').AsInteger;
          FieldByName('SATISURUNSTOKID').AsInteger := 

Srgurunler.fieldbyname('STOKID').AsInteger;
          FieldByName('SATISURUNMIKTARI').AsInteger := cxSpinEdit1.Value;
          FieldByName('INDIRIMORANI').AsInteger := 

dtsSATISlar.fieldbyname('SATISINDIRIM').Value;
          FieldByName('NETTUTAR').AsCurrency := ((cxSpinEdit1.Value * 

Srgurunler.fieldbyname('STOKSATISFIYATI').AsCurrency) - ((cxSpinEdit1.Value * 

Srgurunler.fieldbyname('STOKSATISFIYATI').AsCurrency) * 

dtsSATISlar.fieldbyname('SATISINDIRIM').Value / 100));
          FieldByName('SATISURUNSATISFIYATI').AsCurrency := 

Srgurunler.fieldbyname('STOKSATISFIYATI').AsCurrency;
        end
      else
        begin
          Edit;
          FieldByName('SATISURUNMIKTARI').AsInteger := 

FieldByName('SATISURUNMIKTARI').AsInteger + cxSpinEdit1.Value;
        end;
      post;
      trsSATISUrunler.Commit;*
      ledSatir1.Scrolling := false;
      ledSatir1.Caption := IngilizceTurkce(Srgurunler.fieldbyname('STOKADI').asstring);
      ledSatir2.Caption := SolaHizala(inttostr(cxSpinEdit1.Value) + ' X ' + 

floattostr(Srgurunler.fieldbyname('STOKSATISFIYATI').AsCurrency) + ' YTL');
      cxSpinEdit1.Value := 1;
      cxGridDBTableView1.DataController.Search.Cancel;
      dtsSATISUrunler.Active := true;
    end;
end;

Hocam işte kodlar burada. Başımıza böyle birşey gelmese dert yanacak halimiz yok. Ancak * işaretli yerde normalde commitretaining kullanmak gerekir. commitretaining yaptığımız zaman hiçbir hata olmadan kayıt giriliyor. Hatta diğer açık satışlara geçip başka ürünler eklenebiliyor. Ancak daha sonra bu satışa geri dönüpte kapat denildiği zaman, satış kapanıyor ancak kullanıcının haberi olmaksızın bazı ürünler iptal ediliyor ve bu akşam Z raporunda kendini gösteriyor.

** Bu arada bir tablodan bahsediyorsak her zaman tablolar satır ve sutunlardan oluşur. Bu bir excel tablosu bir html tablo veya bir veri tabanı tablosu olabilir. Ben bu yüzden kayıt eklemek için satır ekleme deyimini kullanmakta bir sakınca görmüyorum.

[Terminator]

Ali,
dediğim gibi firebird commitretaining için farklı bir transaction yöntemi kullanmıyor. commitretaining commit edilen transactionın yerine yeni bir numara alınırarak commit emri gelmemiş gibi işlemlerin kaldığı yerden yeni numrayla devam ettirilmesidir.
transactionların kesin kaydını onaylayan transaction inventory pagelere yazılan transaction takip kayıtlarıdır.

senin kullandığın komponentteki bir bug veya eksiklik veya özellik nedeniyle belki commitretaining komutun serverdan hata döndüğünde
kesilmeye neden olmuyor olabilir.
belki de server çok fazla commitretaining yaptığın için kaynakları tüketmiş ve yeni transactionu başlatamamış da olabilir. kritik komutların
sonuçları daima kontrol edilmelidir. commit komutun ise mutlaka çalışır çünkü yeni bir transaction başlatmıyor, tersine server sistem kaynaklarını serbest bırakıyor.

[aLonE CoDeR]

Kodlamanda anormal şeyler var.Örneğin önce append akabinden edit editmişsin dataseti, buradaki maksat nedir, bunun birçok veri tutarsızlığını beraberinde getireceğini sanırım biliyorsundur..Ek olarak sen normal bir post işlemi gerçekleştiriyorsan buradaki kod bloklarının içinde spesifik bir commit/commitretaining kullanma ihtiyacını neden duydun bunu da çözemedim.Özellikle network ortamlarında bu tür spesifik commit ve muadili işlemler veri tutarsızlığı için en önemli sebeplerden biridir.Insert ya da Update için kullandığın transaction nesnesi baz alınmak kaydıyla bir bilemedin iki yerde commit ya da muadili bir komut icra ettirmek gerekir.Özellikle hızlı satış sistemleri söz konusu olduğunda ve bir de network yükü fazlaysa bu organizasyon hataya davetiye çıkartır..Bu noktada commitretaining bazen iptal ediyor demek pek sağlıklı bir hüküm değil fikrimce..

Kolay gele..

[meron06]

Terminatör usta "yani bu teknikle bulk insert yapılmaz." demişsiniz.en uygun teknik sizce hangisi biraz açıklayabilmeniz mümkünmü.

[Terminator]

Terminatör usta "yani bu teknikle bulk insert yapılmaz." demişsiniz.en uygun teknik sizce hangisi biraz açıklayabilmeniz mümkünmü.

bir tane insert query yaz ve gereken insert kadar
parametrelerine atama yaparak execute et.
böylece query sadece bir kere yapılandırılıp sadece
parametre ataması yoluyla sürekli aynı komut olarak en hızlı şekilde işlenecektir.
tabi bu queryini herhangi bir componente "bağla-ma-man" gerekiyor.
random kayıt girişi değilse bulk insertler genelde fixed size dosyalardan okunarak yapılır. öyle durumlarda ise, zaten herhangi bir döngüye gerek yok, kaynak dosyayı external table olarak tanıtıp hedef tabloya tek bir sql cümlesiyle en hızlı şekilde aktarabilirsin. bunun için external dosyanın firebird serverin erişebileceği bir pathte olması gerekir ve firebird.conf dosyasından erişim izni verilmiş olmalıdır.