udf in einem Connect-Trigger

Forum zu diversen Themen rund um die Firebird-Programmierung

Moderator: martin.koeditz

Antworten
zappa2
Beiträge: 11
Registriert: Fr 5. Okt 2018, 10:59

Fr 11. Okt 2019, 11:12

Ich schreibe gerade einen connect-Trigger, der bei Start einer Connection eine Global Temporary Table (GTT) mit aktuellen Daten befüllen soll.

Diese Daten werden mittels mehrerer udf aus einer anderen DB gelesen.

Solange ich das alles in einer einfach StoredProc mache, ist alles okay. Diese lässt sich beliebig oft ausführen, die GTT wird wie gewünscht befüllt.

Führe ich aber diese StoredProc innerhalb eines connect-Triggers aus, hängt sich die DB auf. Ich habe mal ein wenig damit rumexperimetiert: die DB bleibt sofort hängen, sobald ich auch nur eine einzige der udf aufrufe.

Das sowohl im IBExpert als auch in DBeaver und natürlich auch in jeder Client-Anwendung, die sich auf diese DB connecten will.

Wo ist das Problem? Die andere DB, aus welcher ich über die udf die Daten hole, hat keine connect-Trigger.

Nachtrag: Solange die udf keine DB-Verbindung zur anderen DBs aufbaut, gibt es keine Probleme.
Benutzeravatar
martin.koeditz
Beiträge: 140
Registriert: Sa 31. Mär 2018, 14:35

Fr 11. Okt 2019, 22:37

Hallo zappa2,

wie sieht die UDF aus? Hast du mal einen Trace mitlaufen lassen? Dort kann man meist schon das eine oder andere Problem erkennen. Wenn ich es richtig verstehe, erhältst du keine Rückmeldung von der DB. Vielleicht ist dies auch ein Bug. Welche DB-Version setzt du ein? Welches Betriebssystem? Bit-Variante?

Vielleicht kannst du ein Test-Skript einstellen, dass weitestgehend zusammengekürzt ist. Dann gibt es die Möglichkeit das Problem zu verifizieren und ggf. einen Bug bei den Entwicklern einzustellen. SP und UDF sollten ziemlich identisch laufen. Es sei denn du "überschreibst" eine bestehende Firebird-Funktion. Ich glaube, das ist möglich.

Gruß
Martin
Martin Köditz
it & synergy GmbH
zappa2
Beiträge: 11
Registriert: Fr 5. Okt 2018, 10:59

Mo 14. Okt 2019, 18:19

Hallo Martin,
wie immer erst mal besten Dank für die schnelle Unterstützung!

Ich habe das jetzt mal auf ein Minimal-Beispiel runter gebrochen, auf einen einzigen simplen udf-Aufruf (Abfrage eines Integer-Outputs mit 2 String-Input-Parametern).

Das Ergebnis ist mehr als eindeutig:
Als StoredProc läuft es wie erwartet auf beiden Versionen klaglos.
Der Unterschied kommt bei den Connect-Triggern:

Firebird 3.0 => alles o.k.
Firebird 2.1 => bleibt hängen, nimmt gleich den ganzen DB-Server mit ins Nirvana.

Ich werde da jetzt auch nix mehr an Energie reinstecken. Auf 3.0 funktioniert es klaglos, warum soll ich das irgendwie auf antiquarische Altlasten portieren.

Ich will mich am Wochenende auf der Firebird-Konferenz mal schlau machen, was dagegen spräche, Uralt-2.1-DBs auf 3.0 (evtl. sogar schon auf 4.x, falls es da schon eine 'stable Version' gibt) zu heben. Ich vermute mal, der einzige Stolperstein könnte irgendwie mit CharSets zu tun haben.

Noch mal Danke und beste Grüße
Jürgen
Benutzeravatar
martin.koeditz
Beiträge: 140
Registriert: Sa 31. Mär 2018, 14:35

Di 15. Okt 2019, 17:57

Hi Jürgen,

es gibt noch einen weiteren wichtigen Punkt zu beachten. Aus Kompatibilitätsgründen wurden die Kontextvariablen
LOCALTIME und LOCALTIMESTAMP eingeführt. Unter 3.0.4 sind diese als Synonyme für CURRENT_TIME und CURRENT_TIMESTAMP zu betrachten. Letztere werden in 4.0 neu definiert.

Siehe auch:
https://firebirdsql.org/file/documentat ... l#d0e10590

Gruß
Martin
Martin Köditz
it & synergy GmbH
Antworten