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