Ne možeš commit-ovati transakciju u triggeru, niti u proceduri. Ali možeš u DataSet.AfterPost da dodaš ... MyTrans.CommitRetaining (MyTrans je komponenta koju koristiš za kontrolu transakcije tog dataseta).
CommitRetaining ti radi samo u FB (nisam 100% siguran ali mislim da je tako), i to znači da je uradio Commit, ali ti ne zatvara transakciju, tako da možeš nastaviti rad u njoj. Ali je vrlo preporučljivo da pre zatvaranja forme ipak uradiš pravi Commit, zbog nekih internih stvari u FB.

A to što nešto menjaš u triggeru Before Update ne bi trebalo da smeta, osim ako si nešto zakomplikovao. Promene bi trebalo da radiš u sledećem stilu:
new.MyField = 100;
a ne
Update MyTable set MyField = 100 .... where new.pk=....

trigger nije kopliciran...

vuce neke sume iz drugih tablica...
ali commmitretaining nije dobro rijesenje (zbog petlji)

naso sam komponente fibplus koje imaju autocommit koji odgovara i radi sta ja hocu

CommitRetaining ne treba koristiti, u nekim slucajevima koriscenja moze doci i do ozbiljnih problema. Inace je postojao jos u IB-u. Programera lako ponese jedina njegova svetla strana da kursori nad bazom ostaju otvoreni posle njegovog izvrsenja sto nije slucaj sa cistom commit varijantom. Ali i to se da srediti sa pametnim pristupom.

U svakom slucaju stvari funkcionisu ovako:

Onog trenutka kada korisnik A izmeni neki slog a ne zatvori transakciju taj slog ostaje zakljucan (server postavlja lock na njega) za druge korisnike i njihove transakcije dokle god korisnik A ne uradi commit ili rollback. Zato transakcije treba da budu sto krace kao bi eventualna zakljucavanja bila sto kraca. Otvaranje transakcije prilikom ulaska u neku formu i njeno zatvaranje po izlasku iz forme je veoma lose resenje kada se na bazu kaci vise od jednog korisnika istovremeno, a moguce je napraviti problem i sa jednim korisnikom koji startuje dve transakcije koje rade nad istim podacima. To znaci da korisnik Pera moze da otvori tu formu i da ode na dorucak, pri tome blokirajuci rad drugih korisnika dokle god se ne vrati sa dorucka. Znaci transakcije sto krace treba da traju, i ako je to moguce da se ne preteruje sa kolicinom izmena u okviru jedne transakcije. Ovo je zbog toga sto svaka transakcija trosi odredjene resurse na serveru i sto moze doci do negativnog uticaja na performanse i stabilnost servera.

FIB moze da radi u rezimu kratkih transakcija, i nema ovaj problem; otvara transakciju da bi uzeo podataka i odmah je zatvara, isto tako i prilikom insert, update i delete komandi. Medjutim ukoliko je potrebno vezati vise izmena nad bazom mora se rucno startovati i zatvoriti transakcija pod kojom se rade te izmene, naravno gledajuci da to traje sto krace.