Mein Problem tritt im Lazarus-Clientprogramm auf. Im IBExpert habe ich diese Effekte nicht.
Ich habe in meiner DB eine GTT (ON COMMIT PRESERVE ROWS => also connectiongebunden und nicht transactiongebunden soviel ich der FB-Doku entnehmen konnte).
Nun habe ich einen View, der sich über einen Join auf diese GTT bezieht.
Öffne ich nur diesen View in einer Select-Query ist alles okay, solange diese Qry eine eigene Transaction bekommt und nicht an der Transaction von der Connection hängt.
Führe ich allerdings eine StoredProc (ebenfalls eigene Transaction) aus, die auf diesen View zugreift, kommt nix raus. Die gleiche SP im IBExpert bringt hingegen genau das, was ich erwarte.
Wo liegt mein Denkfehler?
Global Temporary Table und Transactions
Moderator: martin.koeditz
Prüfe mal, ob du wirklich in der selben Connection arbeitest.
https://firebirdsql.org/refdocs/langref ... ction.html
Je nach Programmiersprache wird gerne mit einem Connection-Pool gearbeitet, so dass du u.U. nicht garantieren kannst, die Aktionen innerhalb der selben Connection durchgeführt zu haben.
GTT's wirken immer nur in einer Connection. Wird diese geschlossen (committed), ist die GTT wieder frei.
Bei Pooling (ins besonders bei Web-Anwendungen) kann das dann so fatal werden, dass der Inhalt der GTT plötzlich eine ganz andere Sitzung bekommt, da im Pool die Connection nicht geschlossen wird.
Im IBExpert hast du i.d.R. ja nur eine Connection.
https://firebirdsql.org/refdocs/langref ... ction.html
Je nach Programmiersprache wird gerne mit einem Connection-Pool gearbeitet, so dass du u.U. nicht garantieren kannst, die Aktionen innerhalb der selben Connection durchgeführt zu haben.
GTT's wirken immer nur in einer Connection. Wird diese geschlossen (committed), ist die GTT wieder frei.
Bei Pooling (ins besonders bei Web-Anwendungen) kann das dann so fatal werden, dass der Inhalt der GTT plötzlich eine ganz andere Sitzung bekommt, da im Pool die Connection nicht geschlossen wird.
Im IBExpert hast du i.d.R. ja nur eine Connection.