işlem gören kaydın durumu.

[fduman]

Haklısın @Terminator FB transaction sistemini daha yakından incelemeliyim.

Sağolasın.

[Terminator]

sen bir kaydın locksız olduğu bilgisini alıp değerlendirene kadar binlerce
defa o kaydın lock durumuna geçip değişebileceğini düşünemiyor musun?

bilgiyi degerlendirme sureci biraz da kodun nasıl yazıldığına bağlı.
mesela

kaydet dugmesinde yer alan kodlar şu şekilde olsun

Kod: Tümünü seç

KaydiDuzenlemekIcinAc
DegisiklikleriYap
Kaydet
If IslemBasarisiz KullaniciUyar

bunlar ardarda isleyen komutlar , dolayisiyla araya bir baska kullanicici girme ihtimali cok az. kaldiki araya bir baska kullanici girsin. yapilan islemlerin sonucunda ib/fb geriye sorunun ne oldugunu acikca belirten bir cok deger donduruyor. benim istedigimde eger bir lock yuzunden benim islemim basarili olamamışsa fb nin geriye xxxxxx gibi bi hata degeri dondermesi. bende bu hata kodunu isleyerek kullaniciya "uzerinde calistiginiz kayit bir baska kullanici tarafindan degistirilmekte oldugu icin isleminizi su an gerceklestirilemiyor. lutfen bir kac dakika sonra tekrar deneyin" mesajini vermek istiyorum.

bu sistemde bir kullanicinin bir kaydi kilitleyip yemege gitmesi ise zaten soz konusu degil

Sadettin,
Söylediğin lock handle etme olayı FB de ilk günden beri var.
Bunun delphiyle cobolla da bir ilgisi yok. hatta size bi bilgi vereyim..
şu ağ trafiğinde varcharlar ve charlar neden blank filled olarak gerçek boyunda gidiyormuş biliyor musunuz?
80 yılllarda COBOLcu salaklar, değişken string değişkenleri handle edemedikleri için jim amca böyle yapmak zorunda kalmış.

neyse konu bu değil.
siz bir datasetini edit moduna geçirdiğinizde, local buffer kopyasını edite geçirirsiniz, yaptıgınız için DB ile bağlantısı yoktur. edit bir component kayıt editleme emridir.
editiniz bitince post ettiğinizde bu DB ye gönderilir ama, sizin okuduğunuz kayıt güncelliğini kaybettiği için artık update edilemez. kayıt bütünlüğü bozulur yoksa.
kayıt bütünlüğü nedir diyenlere ayrıntıya gireyim:
okunmuş bi kayıt değiştirilmişse sizden sonra, mesela siz miktar sahasını 2 yaparsınız, diğer kullanıcı fiyatı 4000 yapar, ikinizinde istemediği bir kayıt oluşur. çünkü 2 yapan fiyatı 1000 bilerek yapar, 4000 yapan ise miktarı 5 bilerek yapar gibi.. sonuçta tutar, her iki tarafın da istemediği bir sonuç olur.
Sizin yapmanız gereken, eğer bu şekilde pasif update yapıyorsanız,
dönen hatayı handle edip koduna göre lock oldugunu anlamak ve kullanıcıyı yönlendirmektir.
işiniz çok ciddiyse eğer, edit işleminin yanında o kaydı lock amaçlı select etmenizde fayda var, ya da o kaydın herhangi bir sahasını değiştirerek sizin için kilitlenmesini sağlamalısınız.
bütün bunlar bütün sistemlerde var, FB le ilgisi yok, nasıl bir sistemden geldiniz de bunları bilmiyorsunu, nasıl kod yazıyorsunuz aklım almıyor.
meydan savaşı yapar gibi kodlama yapılmaz, devir akıl devri, millet oturduğu yerden 2 tuşla yönetiyor, savaşıyor, kazanıyor.
Sizden kimse tekerlek icadı beklemiyor, en azından kullanma klavuzunu okuyun, eğitimini alın, o şekilde kullanın arabayı. aklınıza gelen her vitesi rastgele geçirmeyeceğinizi, trafik kuralları olduğunu, kullanım maliyeti oldugunu, dikkati elden bırakmamanız gerektiğini öğrenin.

[musti]

merak ettim terminator. Hep yadırgıyorsun. kucumsuyorsun, beceriksizler diyorsun ve bizde sana sabrediyoruz. sence bilgi almak isteyen bizler senin formlarına girmesek daha mı iyi olur. ama inan amacımız birseyler öğrenmek. Ben bu siteye birseyler öğrenmek eğer bildigimiz varsa da paylasmak isterim ama adabı usulden dolayı buyuklerimiz dururken ben pek cevap vermem. zaten cok bise bildigim yok. Neden abi sen boyle mıncıklaya mıncıklaya birseyler yazıyorsun. yazdıklarına baktım acaba ben duygusal davranıp haksızlıkmı ediyorum baktım abi sadece ben değil en ustalarada bunu yapıyorsun. Yazdıkların cok net degil acıklayıcı da degil hep birseyle gizli bu bana bilgisini saklayan ama bilgili oldugunu göstermek zorunda olan bazı ustaların mektuplarını hatırlattı.
Düsünüyorum bir seyler öğrenmek icin buna katlanmak gerekiyormu ?
Yinede özür dilerim lütfen yanlıs bir anlasılma olmasın.
Umarım biglileriniz bu siteye faydalı olur. Çünkü ben butun zorlamalama karsın bir sey öğrenemedin. sizde demiştiniz ya benim seviyeme inme sansınız yok. eğitim eksikliğimi var (haklısın) ama birsey öğrenmek icinde hakarete ugramak dogrumudur bilmem.

Tekrar özür dilerim vermiş oldugum rahatsızlıkdan dolayı

Saygılarımı sunarım bütün okuyanlara.

[fduman]

@musti hakaret yok ortada. Kapatalım konuyu. Buna yanıt da yazmayalım lütfen. Topic iyi gidiyor çünkü.

@Terminator haklı, o da transaction'lar konusunda gerçekten çok bilgili değilim, çalışmam gerekiyor. Hatta çalışmaya başladım bile.

Burada http://www.interbase-world.com/en/articles/805.php kayıt kilitleri hakkında güzel bir makale var.

http://www.interbase-world.com/en/articles/532.php burada da transaction'lar hakkında.

Örnekler FibPlus üzerinden verilmiş ancak eğitici.

Çalışalım öğrenelim.

[musti]

siz öyle diyorsanız öyledir abi özür dilerim.
abi elinizde sanırım silin bu iki mesajı insanlar rahatsız olmasın. haklısınız öğrenmek icin çalışmalıyız.Aslında cok terettüd ettim yazarken sonra silemedim.

tsk ederim.

[Terminator]

Bilimin, teknolojinin kendi dili, jargonu ve kuralları var ve onu kullanmak gerekir. Söylediklerim, kullandığım kelimeler, bana özgü kelimeler kurallar veya keyfi tanımlamalar değil. Kaldı ki ben, bir teknik konuyu anlatırken en az teknik dili kullananlardan biriyim ve genelde gündelik örnek ve cümlelerle fikir vermeye çalışırım ve bu herkesin hoşuna gidiyor.

Teknik konularda detay istiyorsanız, ER modelleme, Veritabanı tasarımı, RDBMS prensipleri, SQL standartları, vs konularında forumlar açmanız takip etmeniz gerekir.
Üniversitelerde 5-6 senede, derceye girip okumuş zeki adamların bile zor muaffak olduğu teknik detayları birkaç forum mesajıyla sindrebileceğinizi düşünüyorsanız bile, şikayetçi olunacak kişi ben olmamalıyım. Ben bildiklerimi öğretmekten çok yeni bişeyler keşfetmekten zevk alan bir insanım, ne biliyorsam ve becerebiliyorsam bunu kendim başardım, bunu benim gibi biri yapabiliyorsa siz de yapabilirsiniz, hadi bakalım pamuk beyinler okumaya, öğrenmeye,
denemeye, gelişmeye. en büyük ibadet aklı yüceltmektir, akli ehliyeti olmayanın cezai ehliyeti de yoktur, ama tecrit edilmesi de, idrakinde olmadığı bir özgürlüğün kısıtlanması sayılmaz, hangisi azınlıkta ise o tecrit olur.

[Kuri_YJ]

Selamlar,

Terminator'un kendi üslubu bu şekilde ve bu söylediklerini yerme manasında algılamayın arkadaşlar. Sadece açık gördüğü noktalarda bizlere doğrudan uyarıyor. Dolandırmadan dolaysız, saf bir şekilde. Ama malesef bu tarza hepimiz alışık değiliz. Fakat şundan eminim, Terminator Art niyetsiz olarak gördüğü açıkları söylüyor.

Bununla yetinmeyip, nerelerin açıkta kaldığı ve nelerin sağlanması konusunda da fikir söylüyor. Ha tarzı tam bir Terminator tarzı

O sebeple alınganlık yapma Musti Biz seni seviyoruz, öğrenmen içinde gayret gösteriyoruz.

Kolay Gelsin

[sadettinpolat]

Sadettin,
Söylediğin lock handle etme olayı FB de ilk günden beri var.

yahu bu topik neden bu kadar uzadı anlamadım
soru gayet açık ve net
kayıt kilitlenmiş ise bunu kullanıcıya bildirmek istemiş programcı.
terminatör'un de belirttiği gibi fb bunu handle edebiliyormuş
bu konulardan taaa transactionlara kadar uzadık.

sorun şu fb nin handle ettigi bu olayı ben bi turlu yakalayıp işleyemedim
bu tür durumlarda ekrana hep deadlock mesajı çıkartıp duruyor fb. ben bunu ne kadar try - excpet içine alsamda bu mesaj kullanıcının karşısına çıkıyor. ben ve topiği açan arkadaş bunu istemiyor. kullanıcını karşısına bizim yazdığımız bir mesajın çıkmasını istiyor.

transactionı ise daha detaylı bir başka topicte incelemek lazım
raporlamada hangi izolasyon düzeyi
replikasyonda hangi izolasyon düzeyi gibi soruların cevaplarını ayrı bi başlıkta terminatöre soracam zaten

[aLonE CoDeR]

Benden de benzer birşey istediler, aynı şeyi benim de sormam gerek şimdi..

Kod: Tümünü seç

Select alan from tablo where... with lock

Bir kaydı edit ettiğimizde bu şekilde kilitledikten sonra Application Events kullanarak mesajı Türkçeleştirebileceğimizi sanıyorum ancak;

- Bunun için istisnai durumlar var mı?
- @coderlord'un söylediği gibi kaydı kimin lock ettiğini ek bir işlem yapmadan FB bize sunuyor mu?
- UnLock işlemi için commit her durumda yeterli olur mu?
- Bu konunun direkt transactionla ilgisi var mı?

bilmek istiyoruz...

[Terminator]

Benden de benzer birşey istediler, aynı şeyi benim de sormam gerek şimdi..

Kod: Tümünü seç

Select alan from tablo where... with lock

Bir kaydı edit ettiğimizde bu şekilde kilitledikten sonra Application Events kullanarak mesajı Türkçeleştirebileceğimizi sanıyorum ancak;

- Bunun için istisnai durumlar var mı?
- @coderlord'un söylediği gibi kaydı kimin lock ettiğini ek bir işlem yapmadan FB bize sunuyor mu?
- UnLock işlemi için commit her durumda yeterli olur mu?
- Bu konunun direkt transactionla ilgisi var mı?

bilmek istiyoruz...

... For update with lock
ile, o select ettiğiniz kayıtlar sizin için locklanır,
eğer o kayıtlardan biri ya da bazıları zaten locklı ise başkası tarafından
hata alırsınız, işlemi başarana kadar tekrar denemeniz gerekir.
Uygulama içinde, try blogunu kullanarak bütün hata mesajlarını yakalayıp
istediğiniz yaparsınız, ama kalkıp sitemin msg textini yazdırırsanız tabiki
ingilizce orjinal hata çıkar. hata koduna göre sizin bişeyler yazmanız lazım,
türkçe istiyorsanız. ya da MSG.FDB dosyasını türkçeleştireceksiniz.

Bir kayıtlı locklı mı değil mi öğrenmenin yolu o kaydı değiştirmektir.
burda değiştirmek compenentte kaydı editlemek değildir, kavramları karıştırmayın. kaydı update amaçlı post etmektir. edebiliyorsa, başkasına
locklı değildir ve size locklanır. bundan sonraki commit we rollback işleminizde de kesinlikle lock kalkar, MGA mimarisini anlatmıştım.
ya da lock durumuyla ilgilendiğiniz kaydı bir başka query ile
for update with lock ile select edeceksiniz ve tamam derse, sizindir.
değilse, başkasına locklıdır, bu başkası her an herkes olabilir çok kullanıcılı bir sistemde, ve dediğim gibi kim oldugunu anlayıp bişeyler yapmaya kalkana kadar kayıt binlerce defa bile herkes tarafından değiştirilebilir. O şekilde işlem patalojik vaka olacaktır.

kaydı kimin lock ettiğini öğrendiniz diyelim napacaksınız?
düşünün bir sistemde yüzlerce kişinin sürekli bir kaydı kimin lock ettiğini öğrenmeye çalıştığını ve birbaşkasının lockını kill etmeye kalktıgını..
ya da bunu bir mesaj olarak kullanıcıya sunmak bir güvenlik açıgı değil midir?!
Transaction ne şekilde kapatılırsa kapatılsın, ya da elektrik gitsin, sistem
hiçbir şeyi locklı bırakmaz. bu FB! hiçbir sisteme benzemez, yeni taklitlerine bile.
post_event olayında, ilgili kaydın numarasını ekleyerek, commit durumunda artık özgürleşen kayıtları mesaj olarak iletebilirsiniz.
ama unutmayın o mesaj herkese gidiyor ve herkes aynı şeyi aynı anda yapmak isteyebilir.
bir tablodaki kayıt lockları sizin için kritikse, uygulamanıza
yani bir transaction ekleyin, ve lock edilen kayıtları bir tabloya kullanıcı bilgileri ve kayıt numarasıyla jurnalleyin, jurnali yazar yazmaz o yan transactioni commit edin. böylece, bir kayıt size locklı deniyorsa
gidip jurnale bakıp en son kimin yazdığını alabilirsiniz, ne yapacaksanız, o şekilde değerlendirirsiniz.
ama hepsini aynı transaction içinde yapmaya kalkmayın, ve eventların da
sadece commit bittiğinde gönderildiğini unutmayın. akıbeti belirsiz bir işlem için event gönderilmez, sadece onaylandığında gider.

[aLonE CoDeR]

Öncelikle bilgiler için teşekkürler..

- Application Events kullandığımızda elbetteki hatanın orjinal metnini alırız.Buna, en basit programlama yöntemleriyle müdahale ettiğimizde, örneğin string fonksiyonlarını kullanarak hata metnini -deadlock hatası gibi..- büyük olasılıkla tespit ettirip gerekli Türkçe mesajı verdirebiliriz..Bu konuda herhangi bir sıkıntı(m) yok..

- Anladığım kadarıyla FB bize kaydı kimin lockladığını bildirmiyor (network yoğunluğu, aynı kayda kimlerin erişmek istediği, erişen kullanıcı sayısı vs.ayrı bi konu..), ek yöntemler kullanarak bunu biz halletmeliyiz..Yani farklı bir yerde kayıt locklanırken bağlanan kullanıcı adını da yazdırmak/jurnallemek şartıyla tutabiliriz..Ve buna benzer birkaç yöntem kullanılabilir..

- Bunlara ilaveten commit kullanmak anladığım kadarıyla lock işlemini unlock yapmak için yeterli olmaktadır..

- Son olarak harici bir istisna söz konusu değildir..

Kolay gele..

[NewMember]

@sadettinpolat demişki:

sorun şu fb nin handle ettigi bu olayı ben bi turlu yakalayıp işleyemedim
bu tür durumlarda ekrana hep deadlock mesajı çıkartıp duruyor fb. ben bunu ne kadar try - excpet içine alsamda bu mesaj kullanıcının karşısına çıkıyor. ben ve topiği açan arkadaş bunu istemiyor. kullanıcını karşısına bizim yazdığımız bir mesajın çıkmasını istiyor.

Hocam belki bu işinizi görür.Projemden kopyalıyorum.Yani çalışan ve denenmiş bir kod.

Kod: Tümünü seç

procedure Tfrmmusteri.btduzenleClick(Sender: TObject);
begin
  if datmodul.Sorgu.RecordCount < 1 then//bU BENİM KAYITLARI 
//YAPTIĞIM DATASET
  begin
    exit;
  end;

  //Burada Dikkat edilmesi Gereken Kaydı kitleyen ile edit eden 
//transaction
  //aynı olmalı.
  try
    //Burada Hata Arayacağız.Çünkü Ağ Üzerinde de kullanılacak olan bu programda
    //eğer bir kullanıcı kaydı edit etmeye çalışırken kaydı başka bir dataset
    //ile kilitleyecek.Önce Edit komutunu verecek ve sonra başka bir dataset ile aynı
    //kaydı kilitleyecek.Ama başka bir kullanıcı da ilk kullanıcı commit yapmadan
    //bu kaydı edit etmeye çalışırsa edit kodu çalışacak ancak sonradan gelen
    //Kilitleme kodunda exception yakalanacak.Bizde bu 
//exceptionu Deadlock patrametresi ile
    //Yakalayarak mesaj verip caNcel diyerek rollback yapacaz.   
    KayitModunaGec;
    datmodul.Sorgu.Edit;    
    //Şimdide Değiştiren Kullanıccı İsmini database yazalım.
    datmodul.SorguDEGISTIREN.AsString := Frmana.ComboKullanicilar.Text;
    QueryLock.SelectSQL.Clear;
    QueryLock.SelectSQL.Add('select * from MUSTERI where MUSTERIKODU=:PAR with lock');
    QueryLock.ParamByName('PAR').Value := datmodul.SorguMUSTERIKODU.Value;
    QueryLock.Open; //Edit Edilen Kaydı Kilitle
  except
    on E: Exception do
    begin
      // showmessage(e.classname+' '+e.message);
       // x:=e.Message;
      if Pos('deadlock', e.Message) <> 0 then
      begin
        Application.MessageBox('Bu Kayıt Şu Anda Ağdaki Başka Bir Kullanıcı Tarafından Kullanılmakta.Bir Süre Sonra Tekrar Deneyiniz.', 'Hata', MB_ICONWARNING);
        datmodul.Sorgu.Cancel;
        datmodul.IBTransaction1.RollbackRetaining;
        SorfModunaGec;
        SorguGuncelle := True;
      end; //if sonu
    end;
  end; //try sonu
end;
//==============================================================

kolay gelsin.

[Terminator]

@sadettinpolat demişki:

sorun şu fb nin handle ettigi bu olayı ben bi turlu yakalayıp işleyemedim
bu tür durumlarda ekrana hep deadlock mesajı çıkartıp duruyor fb. ben bunu ne kadar try - excpet içine alsamda bu mesaj kullanıcının karşısına çıkıyor. ben ve topiği açan arkadaş bunu istemiyor. kullanıcını karşısına bizim yazdığımız bir mesajın çıkmasını istiyor.

Hocam belki bu işinizi görür.Projemden kopyalıyorum.Yani çalışan ve denenmiş bir kod.

Kod: Tümünü seç

procedure Tfrmmusteri.btduzenleClick(Sender: TObject);
begin
  if datmodul.Sorgu.RecordCount < 1 then//bU BENİM KAYITLARI 
//YAPTIĞIM DATASET
  begin
    exit;
  end;

  //Burada Dikkat edilmesi Gereken Kaydı kitleyen ile edit eden 
//transaction
  //aynı olmalı.
  try
    //Burada Hata Arayacağız.Çünkü Ağ Üzerinde de kullanılacak olan bu programda
    //eğer bir kullanıcı kaydı edit etmeye çalışırken kaydı başka bir dataset
    //ile kilitleyecek.Önce Edit komutunu verecek ve sonra başka bir dataset ile aynı
    //kaydı kilitleyecek.Ama başka bir kullanıcı da ilk kullanıcı commit yapmadan
    //bu kaydı edit etmeye çalışırsa edit kodu çalışacak ancak sonradan gelen
    //Kilitleme kodunda exception yakalanacak.Bizde bu 
//exceptionu Deadlock patrametresi ile
    //Yakalayarak mesaj verip caNcel diyerek rollback yapacaz.   
    KayitModunaGec;
    datmodul.Sorgu.Edit;    
    //Şimdide Değiştiren Kullanıccı İsmini database yazalım.
    datmodul.SorguDEGISTIREN.AsString := Frmana.ComboKullanicilar.Text;
    QueryLock.SelectSQL.Clear;
    QueryLock.SelectSQL.Add('select * from MUSTERI where MUSTERIKODU=:PAR with lock');
    QueryLock.ParamByName('PAR').Value := datmodul.SorguMUSTERIKODU.Value;
    QueryLock.Open; //Edit Edilen Kaydı Kilitle
  except
    on E: Exception do
    begin
      // showmessage(e.classname+' '+e.message);
       // x:=e.Message;
      if Pos('deadlock', e.Message) <> 0 then
      begin
        Application.MessageBox('Bu Kayıt Şu Anda Ağdaki Başka Bir Kullanıcı Tarafından Kullanılmakta.Bir Süre Sonra Tekrar Deneyiniz.', 'Hata', MB_ICONWARNING);
        datmodul.Sorgu.Cancel;
        datmodul.IBTransaction1.RollbackRetaining;
        SorfModunaGec;
        SorguGuncelle := True;
      end; //if sonu
    end;
  end; //try sonu
end;
//==============================================================

kolay gelsin.

Arkadaşlar, bazı optimizasyon tavsiyeleri:
Hata kodu diye bişey var; sayısal bir değer, integer, bu kodları ve anlamlarını ibphoenix.com dan indirebilirsiniz.
hata mesajının içinden bir kelime aratmak sağlık bir yöntem değil.
aynı kelime farklı bir açıklama için de geçiyor olabilir, yani hata farklıdır,
siz kalkar deadlock diye kullanıcıyı ve uygulamanızı yanıltırsınız.

select * , kullanmamaya çalışmanız gereken bir ifade.
belki serbest SQL yazılan consol tarzı ekranlarda pratik ama
gömülü bir uygulamada, SP de, triggerda kullanmak için bir sebep bulamıyorum.
siz, select 1 from ... ya da select rdb$db_key from.. da deseniz o kayıt okunup işleminiz yapılır.
kullanmayacaksak, bütün fieldları seçtirip işleme sokturmamak daha iyidir.
bunlar artistik veya dekoratif gereklilikler değil, farkı yaratacak kalitedir.

[Terminator]

Öncelikle bilgiler için teşekkürler..

- Application Events kullandığımızda elbetteki hatanın orjinal metnini alırız.Buna, en basit programlama yöntemleriyle müdahale ettiğimizde, örneğin string fonksiyonlarını kullanarak hata metnini -deadlock hatası gibi..- büyük olasılıkla tespit ettirip gerekli Türkçe mesajı verdirebiliriz..Bu konuda herhangi bir sıkıntı(m) yok..

- Anladığım kadarıyla FB bize kaydı kimin lockladığını bildirmiyor (network yoğunluğu, aynı kayda kimlerin erişmek istediği, erişen kullanıcı sayısı vs.ayrı bi konu..), ek yöntemler kullanarak bunu biz halletmeliyiz..Yani farklı bir yerde kayıt locklanırken bağlanan kullanıcı adını da yazdırmak/jurnallemek şartıyla tutabiliriz..Ve buna benzer birkaç yöntem kullanılabilir..

- Bunlara ilaveten commit kullanmak anladığım kadarıyla lock işlemini unlock yapmak için yeterli olmaktadır..

- Son olarak harici bir istisna söz konusu değildir..

Kolay gele..

-Application event dediğin, SQL exception throw dan kaynaklanan bir eventtır, yoksa application bunu lokal olarak kendi üretmez, serverden
dönen exception sonuca göre oluşur. user exceptionları da tanımlayabilirsin FB de, onları da serverdan gönderdiğin noktalarda
uygulaman kesilecektir, except bloguna düşer, ihtimali handle ettiysen try ile.

- Anladığım kadarıyla herhangi bir RDBMS bunu döndürüyor mu? hangisi döndürüyor? peki o dönen sana ulaşana kadar 2-3 kişi daha aynı kaydı sırayla commit edip update ettiyse senin elindeki bilginin nesi işe yarayacak? bu mantık hangi saçma sistemden geliyor bi açar mısın? ben bilmiyorum öyle bir sistem, aklım da almıyor, nasıl tasarlanabilir ve stabil çalışır...

-commit ya da rollback familyasından, transactionı ya da connectionı sonladıran herşey kayıtları çözer, yeni haliyle ya da eskisi olarak.
yani lock sadece, o connection/transaction yaşadığı sürece vardır.

-Harici istisna nedir? ne demek istedin?

[rsimsek]

select * , kullanmamaya çalışmanız gereken bir ifade.
belki serbest SQL yazılan consol tarzı ekranlarda pratik ama
gömülü bir uygulamada, SP de, triggerda kullanmak için bir sebep bulamıyorum.
siz, select 1 from ... ya da select rdb$db_key from.. da deseniz o kayıt okunup işleminiz yapılır.
kullanmayacaksak, bütün fieldları seçtirip işleme sokturmamak daha iyidir.
bunlar artistik veya dekoratif gereklilikler değil, farkı yaratacak kalitedir.

Hocam burası çok önemli. Genelde program yazan ve veritabanı tasarlayan arkadaşlarımız günümüzde yorganlarının terabyte lara kadar uzadığını görüp, nasılsa yer gani düşüncesi ile ayaklarını olabildiğince uzatmaları, el freni çekilmiş arabanın gitmesine benziyor. Perfomans için yapıları çok iyi kurmak gerekir. Page Size uyumundan, alanların gereksiz uzunlukta seçilmesine, SP ve select lerde dediğiniz gibi gereksiz alanların çekilmemesine kadar bir dizi önlemle mevcut imkânlara maksimum perfomansı yakalamak işten bile değil.