Firebird Stored Procedure ve Trigger Bilgisi

[rsimsek]

Hocam ilave olarak transaction un gerekli olduğunu gördüğüm bir yer; eğer yaptığınız işlemlerin ağdaki başka kullanıcılara da yansıması isteniyorsa COMMIT edip tekrar START TRANSACTION yapmak gerekir. Yada, transaction genelde programdan çıkınca sonlandırılır. Biz girdiğimiz bilgilerin başına herhangi bir hal gelmemesi için de COMMIT i tercih edebiliriz.

[ßozis]

Recep abi ben bu dediklerinizi FireBird vt seviyesinde nasıl yapabilirim.
Delphi tarafında start transaction ve commit olaylarını kontrol edebiliyorum ama vt seviyesinde nasıl edebilirim. SP'lerde Trigger'larda veya normal Select segment'lerinde bu start transaction veya commit nasıl kontrol edebilirim.

Teşekkür ederim.

[Kuri_YJ]

Selam,

Ben de Workbench üzerinde denedim ben de de aynı hatayı verdi. Muhtemelen Workbench'in driver'ında sorun var, Yani yorumlayamıyor gibime geldi zira bu set transaction olayı dokumanlarda bangır bangır anlatılan bir şey.

Bir de şuna dikkat etmek gerekiyor. Belki Transaction olayı DSQL PSQL gibi bir ayrımı var onlardan birinde geçerlidir de diğerinde geçerli değildir.

Bakacağım.

Kolay Gelsin.

[rsimsek]

Veritabanı tarafta sql içinde uygun yazılım komutu ile kullanabilirsin. Detayı için InterBase SQL Reference helpine bakabilirsin. Bir iki alıntı..

Syntax
SET TRANSACTION [NAME transaction]
[READ WRITE | READ ONLY]
[WAIT | NO WAIT]
[[ISOLATION LEVEL] {SNAPSHOT [TABLE STABILITY]
| READ COMMITTED [[NO] RECORD_VERSION]}]
[RESERVING <reserving_clause>
| USING dbhandle [, dbhandle …]];

<reserving_clause> = table [, table …]
[FOR [SHARED | PROTECTED] {READ | WRITE}] [, <reserving_clause>]

Syntax COMMIT [WORK] [TRANSACTION name] [RELEASE] [RETAIN [SNAPSHOT]];

Syntax ROLLBACK [TRANSACTION name] [WORK] [RELEASE];

Kolay gelsin.

[onaydin]

Bende ilk mesajda arayıp şunu bulmuştum.
Tam Türkçesi nedir, çalışmaz mı diyor

Firebird PSQL – Restrictions

DDL statements aren‘t supported

Transactions can‘t be started, committed or rolled back. A PSQL code module is always executed within the context of the client transaction (Firebird doesn‘t support embedded transactions)

• Statement types not supported in PSQL
  
  Already mentioned DDL statements, and SET GENERATOR, DECLARE EXTERNAL FUNCTION, and DECLARE FILTER
  
  Transaction control statements: SET TRANSACTION, COMMIT, ROLLBACK
  
  Dynamic SQL statements: PREPARE, DESCRIBE, EXECUTE
  
  CONNECT/DISCONNECT, and sending SQL statements to another database
  GRANT/REVOKE

[ßozis]

Recep hocam bende InterBase'nin Embedded SQL Guide var orrdaki tüm Transaction konularına baktım verdiği örneklerede baktım ama bir türlü beceremedim Exec SQL ile kullanmış bazen SET değilde sade Transaction demiş gibi ama ben halen daha yapmış değilim....

Kuri_TLJ hocam sizinde dediğiniz gibi tüm interbase pdf lerinde sizin dediğiniz gibi yazıyo ama hiç birini çalıştırmış değilim bir EMS ve ibexpert de deniyeceğim ;

Onur hocam Firebird PSQL – Restrictions yazılmış ama hiç bir fikrim yok..

tüm arkadaşlara teşekkürler...

[name]

Bence farklı transactionları çok elzem olmadıkça farklı databaseler kullandığınız zamanlarda çalıştırın. Tek database üzerinde farklı transactionlar mantıklı değil...

Yaptığım programlarda genelde database üzerindeki tablolar ile aynı anda işlem yapma gerekliliği doğuyor. Böyle olunca aynı anda işlem yapacak her bir tablonun transactionı olması gerekli. Aynı anda derken bir tabloda çalışılırken diğer bir tablodada işlem yapılma isteğinden bahsediyorum.

Soru1: Bu durumda database bileşenine bağlanan default transaction sürekli açık mı olucak? Yada problem yaratırmı. Bu soruyu gerekirirse tam açıklaya bilirim.
Soru2: Her tablo için default transactionı kullanırsakta, açık olan iki tablodan birisinde "commit" yaptığımızda diğer tablonun oturumunda (transaction) ne gibi değişim olur.

[sair]

Bakın bir programda tek bir Database (.GDB) kullanıyorsanız tek bir transaction kullanın... Öyle her tablo için bir transaction kullanacaksanız vay halimize... Bir datamodul oluşturun.. Bir Database nesnesi, bir tane de transaction nesnesi koyun.. Bütün tabloları Stored Procları Queryleri de bu datamodule koyarak aynı database nesnesini dolayısı ile aynı transactiona bağlayın... Transaction kavramını da bir inceleyin iyice... Yukardada söylediğim gibi Transaction bir veritabanı oturumudur. Bir veritabanı üzerindeki bütün tablolar procedureler, trigerler her şey ama her şey bu oturuma bağlı olarak çalışırlar. Yani veritabanına Open dediğiniz anda başlar, Commit veya rollback edinceye kadar bütün tablolar stored procedure ler üzerinde yaptığınız işlemler bütünü transactiondur... İki farkı veritabanına aynı anda bağlanacaksanız O zaman 2 database ve 2 transaction kullanmalısınız.. Tek veritabanında farklı transactionlar mantıksızdır...

Cevap 1: Tek veritabanına bağlı olan transaction sürekli açık olacak. Commit veya rollback edinceye kadar veya program sonlanıncaya kadar. Tek transaction üzerinde her türlü işlemi yapabilirsiniz..
Cevap 2: Commit olayı transaction işlemini sonlandıracağı için bütün tablolar otomatik kapanacaktır.... Commit Yerine Tabloların after postuna "IBtransaction1.commitretaining;" yazarsanız sadece o tabloyu commit edersiniz üstelik tablonuzda kapanmaz ve diğer tablolarınız da etkilenmez.. (veya IBTransaction1.Rollbackretaining;)

Sevgiler....

[name]

Merhaba

@sair cevabınız için teşekkürler. Birden fazla transaction kullanma ile ilgili şu an için kafamda bir soru işareti kalmadı. Fakat tek transaction kullanımı ile ilgili affınıza sığınarak bir soru daha sormak istiyorum.

Daha önce forumda, transaction kullanımı ile ilgili, yazdığım bir mesajda, transactionların mümkün olduğunca kısa süreli açık kalmalarının sistemin düzgün işleyebilmesi için gerekli olduğu belirtilmişti. Aynı zamanda data bozulmalarının da önlenmesi için bunu yapmak gerektiği vurgulanmıştı.

Soru: Tek transaction kullanarak oluşturduğum sistemde transactionların programın işleyişi süresince açık olmasında bir sakınca varmıdır?

Not: Belirttiğim mesajın linki viewtopic.php?t=1838&start=15

[freeman35]

walla benimde kafamda soru işaretleri oluştu. Bu güne kadar kullandığım yöntem, her işlem bloğuna ki genelde bu her form denebilr. Yani fatura irsaliye vs gibi bir şey olabilir. Bunların her birine bir transaction koyuyorum ve bunu kullanıyorum. Tabi bidetane default transaction olmak zorunda. bu arada IBX için konuşuyorum. bu default transactionı ben hiçbir şey için kullanmıyorum. Aynı anda Fatura ve irsaliye açık olabilir. bu durmda cari kart ve cari hareket kartlarıda etkileneceği için her ikisi içinde IBQuery koymam gerekir. nedeni fatura kaydedilmeden irsaliye kaydedilebilinir, bu işlemlerin birbirlerini etkilememesi gerekir. Yani transactionları ayırmam gerek.
BDE de tek transaction tanımlanıyor. buda yukarıdaki bahsettiğim sistemin tasarımını oldukça zorlaştırıyordu tabiki. şöyle düşünün fatura, tahsilat, irsaliye tediye, sipariş çek formlarının hepsinin açık, hepside cari hesapları etkiliyor, faturada 3 tane kayıt var ve commit edilmemiş, ama o sırda tahsilat yapması gerekiyor ve tahsilat makbuzu kesiyor, ama yazıcı değiştirmesi gerek, yazıcıda irsaliye var ki daha tahsilatıda kaydetmedi ve irsaliye kesti (commit)bir tane sonra tahsilat makbuzdan vazgeçti(rolback) tediye yaptı(commit) faturaya devam etti. (ne senaryo yazarmışım bende ) tek transactionda bunlar darmadağın olmazmı ? olmaya bilir ama çok kastırır, onun yerine her birine transaction bağlanırsa hepsi birbirinden bağımsız işlem grubu olarak algılanır.
Birde şu dikkatimi çekmişti, IB5x zamanında array a takmıştım, baya bi araştırdım ve IBO yu bulmuştum, ozamanlardamı yoksa yakın zamandamıydı net hatırlamıyorum, ama IBO query lerinde 2 adet farklı transaction bağlanabiliyordu. yani master ve detail table lar her biri ayrı ayrı bir transaction da toplanıyor, daha sonra bu 2 query 1 transactionda bir araya toplanıyor. Bencede çok kullanışlı bir sistem. ama maalesef IBO bana pratik gelmemişti.(extra maliyet )

kolay gele

[Kuri_YJ]

Selamlar,

Onaydin'ın bulduğu PSQL'de geçersizdir anlamına geliyor Bu sebeple olmuyordur diye tahmin ediyorum.

Ancak ben de bir ekleme yapmak istiyorum, öyle anlar oluyor ki, mevcut transaction'ın dışında ekstra ara transaction'lara ihtiyaç duyabiliyorsunuz. Örneğin fatura ve ödeme kaptmaların otomatik FIFO'lanmasında veya benzeri olarak üretim ağacı oluştururken veya Malzeme İhtiyacı çıkarırken bazı durumlarda Transactionları içi içe kullanmak durumunda kalabiliyorsunuz. Bu sebeple birden fazla Transaction kullanılabilmekte, ama yine de aslında Tek bir transaction kullanmak daha iyi bir metod zira server'ı da sıkıştırmamış olursunuz

Kolay Gelsin.

[selm@n]

SelamunAleykum;
Şu SP'lerde ve trigger'lar TransAction kullanımı ile ilgili bir forumda bir soru yakaladım elemanın biri şöyle bir şey sormuş;

Kod: Tümünü seç

I want to be sure that the insert is really committed, so I thought to just put a commit statement in my stored procedure. This doesn't seem to be possible with firebird. Or am I using the wrong syntax for the commit??

This is my procedure:
create procedure test
as
begin
insert into test_table(id) values (1);
commit;
end

Upscene Productions 'dan
Martijn Tonies Cevabı

Kod: Tümünü seç

Transactions cannot be started/committed/rolled back from inside stored procedure or trigger code.

The client (process) that calls the stored procedure should start and commit/rollback the transaction.

dün etkinlikte gökmen hocam ile konuştuk Firebird 'e SP ile trigger içinde TransAction kullanımı olmuyor diye ....

[rsimsek]

Sanırım hatanın sebebi procedure nin içinde transaction başlatmadan commit etmeye çalışmaktır. Yani buradaki commit asıl transaction ın içindeki/iç transaction ı hedef almaktadır.