Firebird Statements "idle" trotz beendeter Abfrage

[ZOD]

Hallo Zusammen,

ich beobachte auf meinem FB4 Server mit diesem Statement

Code:

select
att.mon$user,
att.mon$remote_address,
stmt.mon$sql_text,
stmt.mon$stat_id,
cast(stmt.mon$timestamp as timestamp)
from mon$attachments att
join mon$statements stmt on att.mon$attachment_id = stmt.mon$attachment_id
where
att.mon$attachment_id <> current_connection
and
stmt.mon$state in (0, 1, 2)

die Zugriffe. Infos dazu sind hier zu finden.

In meiner Anwendung verwende ich SQLExpress Komponenten (TSQLConnection und TSQLDataSet).
Der typische Ablauf (Pseydocod - nur prinzipiell) ist dann:

Delphi-Quellcode:

SQLDS : TRMSQLDataSet;
.
.
SQLDS.Active := False; // 
SQLDS.Prepared := False; // ist eigentlich unötig, hier nur zur Information
SQLDS.CommandText := 'select xyz from table'; // nur Beispiel
SQLDS.Prepared := True;
SQLDS.Active := True;

... Daten werden weiter verarbeitet, dann:

SQLDS.Active := False;
SQLDS.Prepared := False;

Nun bemerke ich, dass z.B. das o.g. Statements in dieser Liste der Statements verbleiben ist, es hat mon$state = 0.

Hier ein Auszug aus der FB Doku:

Code:

MON$STATE SMALLINT Statement state: 0 - idle 1 - active 2 - stalled

Das Statement verschwindet erst, wenn die DB Verbindung von meiner Anwendung geschlossen wird.
Aktuell möchte ich wenn möglich vermeiden, dass meine Anwendung nach jeder DB Abfrage die Verbindung schließt und ggf. für die nächste Abfrage neu aufbaut.

Die Standardeinstellung der Transaktion ist

Code:

TransIsolation=ReadCommited

(wird in TSQLConnection eingestellt).

Wird beim DB-Abruf aus meiner Anwendung nun z.B. eine Stored Procedure angestprochen, so kann diese nicht neu kompiliert werden.
Ich vermute, weil das Statement in

Code:

mon$statements

aufgeführt ist.

Kann mir jemand erklären, warum die Statements trotz beendetem Abruf in

Code:

mon$statements

bleiben und vielleicht hat sogar jemand eine Idee, wie ich das ändern kann?

Danke für Tipps und Hilfe.

Gruß
Markus

[mkinzler]

Wie sieht es mit der Transaktionssteuerung aus?

[peterbelow]

Hast Du mal versucht nach dem Schließen der Query ein explizites Commit zu machen?

[ZOD]

Zitat:

Wie sieht es mit der Transaktionssteuerung aus?

Für normale Abfragen wie z.B. Abfrage von Tabelleninhalten zur Information verwende ich keine expliziten Transaktionen (i.m.h.o. wird für eine Abfrage vom Server automatisch eine Transaktion gestartet).

Mhmm, wenn der Gedankenanstoß richtig ist, müsste ich ein

Code:

commit;

senden?. Dann muss ich mir überlegen, wie ich das am besten mache. Die Anwendung ist schon ein wenig größer und es werden natürlich auch an vielen Stellen DB Abrufe in der geschilderten Form getätigt. Eine Info noch: die Anwendung läuft nun schon ein paar Jahre, das hier von mir angesprochene Problem ist also sicher nicht "neu" - jedoch auch nicht "mortal", nur unschön.

Ich melde mich, wenn ich etwas rumprobiert habe.

Danke.

[ZOD]

Ich habe nun versucht, nach

SQLDS.Active := False;

ein Commit zu senden:

Delphi-Quellcode:

SQLDS.CommandText := 'commit;';
SQLDS.ExecSQL;

Dann bekomme ich jedoch den Fehler

Code:

Can't perform operation on inactive transaction.

Es könnte also so sein, wie ich dachte: der Server baut für Statements ohne Transaktionsumgebung ggf. eine "interne" Transaktion auf. Diese kann ich dann natürlich nicht per "commit" beenden.

[ZOD]

Noch eine Anmerkung:

Die FB Doku .. E.8 MON$STATEMENTS

sagt eigentlich klar:

Zitat:

MON$STATEMENTS displays statements prepared for execution.

Ich habe jedoch das Prepare beendet mit

SQLDS.Prepared := False; Mir ist also nicht klar, warum das Statement immer noch in der Tabelle bleibt und bin dankbar für Ideen!
Markus

[IBExpert]

man sollte nicht die qualität der Quellcodes bekannter Komponenten für datenbankzugriffe überschätzen, ich weiss aus jahrelanger erfahrung, das oft die eigentlich offensichtlich funktionierenden Methoden aufgrund von Multiplattform Anforderungen oder sonstiger Gründe gerne mal nur halb umgesetzt wurden. Beispielsweise gibt es gerne mal beim Aufruf der Methode prepare oder unprepare nur dummy code oder seltsame Bedingungen, die nie eintreten. Ob das bei den von dir benutzten Komponenten auch so ist, kann ich nicht sagen, ggf einfach mal die sourcecode dateien, in den die isc api aufrufe oder die gesamte api enthalten ist mit in deinen quellcode pfad packen, so das die dann auch via debugger mit haltepunkten an geeigneter stelle überwacht werden können. oft sieht man dann schon, das es zwar nicht so sein sollte wie man denkt, aber trotzdem oft so ist, wie man meint, das es nicht sein sollte.

im fall prepare war das so, das der prepare zwar implementiert war und auch sauber aufgerufen wurde, beim unrepare hatte der komponenten entwickler aber wohl kein bock mehr gehabt. Ohne funktionierendes prepare hätte die Komponenten bibliothek auch gar nicht funktioniert, ohne unprepare aber schon, daher versuch mal dafürdie implementation zu finden. beim prepare wird ganz sicher irgendwo isc_dsql_prepare im sourcecode stehen.

Es kann aber auch sein, das deine komponente das scheinbar ganz sauber löst, aber mechanismen neuerer firebird versionen den effekt aber so zeigen wie du schilderst.

Da ich aber andauernd mit fb3 zumindest aus lazarus sqldb heraus statements dynamisch erzeuge und auf fb3 datenbanken laufen lasse, weiss ich das es dabei keine statements in der mon$ tabelle bleiben, von denen ich nicht expliziert den prepare stehen lasse. das kann bei fb4 anders sein, bei den kunden wo ich den meisten lazarus code laufen hab, haben wir aber noch fb25 und fb30.

so ein paar basics zu sql statements lifetime findet man übrigens hier
https://www.ibphoenix.com/resources/...eneral/doc_381

[ZOD]

Guten Morgen,

die Idee den Source Code zu prüfen scheitert leider daran, dass ich nur die

Code:

dclcrdbx70.dpk

habe.

Ich habe diese Doku zu "Efficient Unprepare"gefunden. Hier steht:

Code:

New constant DSQL_unprepare available for use with isc_dsql_free_statement for efficient unpreparing of statements

Dazu wird in WEfficient Unprepare" die Anwendung der neuen Konstante näher erläutert.

Das bringt mir leider derzeit - mangels Source - nicht wirklich eine Lösung.

Daher die Frage:
Hat jemand Erfahrungen mit dbExpress Drivers (DevArt Komponente) für den Zugriff auf FB4?

Markus