In allen meinen AdHoc-Abfragen habe ich immer dieses Konstrukt verwendet:
Delphi-Quellcode:
aQuery := TIB_Query.Create(
nil);
try
with aQuery
do
begin
sql.text:=Format('
select acc_profil from t_lms_account where nr=%d for update ',[lms.accountnr]);
ib_Connection := dm.IB_TransactionDefault.IB_Connection;
ib_transaction := dm.IB_TransactionDefault;
open;
Edit;
FieldByName('
acc_profil').AsString := aProfile.AsString;
Post;
end
finally
aQuery.free;
end;
und bin damit einer frühen Empfehlung von Jason gefolgt. Im produktiven Einsatz seit 1998 ist bei mir der von Dir geschilderte Fehler nie aufgetreten.
Gleichwohl gibt es beim Einsatz von Firebird (meine Erfahrung bis V. 2.1) einige Fallstricke. Einer der Wesentlichen: Auf Server und Client muss immer die gleiche gds32.dll verwendet werden. Ich habe dazu diese Datei in das Programm-Verzeichnis gelegt, damit sie nicht durch andere Installationen überschrieben wird (da gab's mal z.B. eine populäre Telefon-CD). Damit sind einige "komische" Effekte aus der Anfangszeit verschwunden.
Zur Transaktion: Es gibt keinen Perfortmance-Verlust, da jede
SQL-Abfrage ohnehin in einer Transaktion abläuft. Benutzt Du Isolation = tiCommitted, solltest Du auch kein Problem mit der Sichtbarkeit haben. IBO verwendet verschieden Timer, um Deadlocks zu lösen. Ich denke, dass bei Dir dieser Fall auftritt. Man sollte z.B. in jedem Formular, eine eigene Transaktions-Komponente verwenden.
Error-Handling: Habe ich zentral auf IB_Connection.OnError abgearbeitet und nicht pro
Query.