[Firebird] Stored proc recompile

[MyRealName]

Hallo,

grad was interessantes gefunden in meiner DB.
ich habe eine SP (Doc_Queue_Process), welches je nach Parameter andere SPs aufruft. Jetzt hatte ich einen Fehler in einer SP, welche von der SP Doc_Queue_Process aufgerufen wird.
nachdem ich den Fehler gefixt habe, im Programm wieder die stelle aufgeruden um zu sehen, dass jetzt alles ok ist, aber immer noch derselbe Fehler :O

Kam raus, dass ich die SP Doc_Queue_Process auch compilieren musste, damit es dann funktionierte.
Ist das normal ?
Gibt es da eine einstellung in Firebird, dass das nicht notwenig ist ?

Danke schonmal
Helge

[mkinzler]

Es gibt die Funktionaltät in den Admintools, abhängige Objekte zu ermitteln bzw. alle SP neu erstellen zu laasen

[MyRealName]

Zitat:

Zitat von mkinzler (Beitrag 1260713)

Es gibt die Funktionaltät in den Admintools, abhängige Objekte zu ermitteln bzw. alle SP neu erstellen zu laasen

dumme Frage am Rande.. in welchen Admintools ? :D

[mkinzler]

IBExpert, Database Workbench, ...

[MyRealName]

Zitat:

Zitat von mkinzler (Beitrag 1260716)

IBExpert, Database Workbench, ...

Das doofe ist ja, ich lasse per Programm mit UniDAC ein script laufen,w elches für die aktuelle Programmversion die SPs/Trigger/Views austauscht. ich kann ja schlecht den IBExpert bei den Kunden installieren ;)

[mkinzler]

Aber ermitteln welche abhängigen SPs es gibt und diese vom Skript ebenfalls neu compilieren lassen.

[Dejan Vu]

Eigentlich dürfte das doch wurscht sein. Wenn ich das richtig verstanden habe, haben wir hier zwei SP: A und B.
A ruft B auf. B wird verändert/korrigiert.

Trotzdem tritt der Fehler beim Aufruf von A immer noch auf. Das kann und darf doch nicht sein!

(Oder habe ich das Problem mißverstanden?

[MyRealName]

Zitat:

Zitat von Dejan Vu (Beitrag 1260720)

Eigentlich dürfte das doch wurscht sein. Wenn ich das richtig verstanden habe, haben wir hier zwei SP: A und B.
A ruft B auf. B wird verändert/korrigiert.

Trotzdem tritt der Fehler beim Aufruf von A immer noch auf. Das kann und darf doch nicht sein!

(Oder habe ich das Problem mißverstanden?

Das ist so gewesen, prgramm neu gestartet nachdem ich die SP gefiXed habe, trotzdem noch den Fehler gehabt, SP B nochmal compiliert, immer noch derselbe Fehler. Dann mal SP A compiliert und schon ging es.

[MyRealName]

Zitat:

Zitat von mkinzler (Beitrag 1260718)

Aber ermitteln welche abhängigen SPs es gibt und diese vom Skript ebenfalls neu compilieren lassen.

Das versuche ich ja zu vermeiden. Das kann ein ganzer Baum sein :(

[mkinzler]

Zitat:

Eigentlich dürfte das doch wurscht sein. Wenn ich das richtig verstanden habe, haben wir hier zwei SP: A und B.
A ruft B auf. B wird verändert/korrigiert.

Trotzdem tritt der Fehler beim Aufruf von A immer noch auf. Das kann und darf doch nicht sein!
Das ist ein Seiteneffekt des Mulitversioning Ansatzes. Solange man A nicht neu kompliliert, verwendet diese die "alte" Version von B.

[mkinzler]

Zitat:

Zitat von MyRealName (Beitrag 1260722)

Zitat:

Zitat von mkinzler (Beitrag 1260718)

Aber ermitteln welche abhängigen SPs es gibt und diese vom Skript ebenfalls neu compilieren lassen.

Das versuche ich ja zu vermeiden. Das kann ein ganzer Baum sein :(

Ist doch egal, ob das Update ein Bisschen länger dauert.

[MyRealName]

Zitat:

Zitat von mkinzler (Beitrag 1260725)

Zitat:

Zitat von MyRealName (Beitrag 1260722)

Zitat:

Zitat von mkinzler (Beitrag 1260718)

Aber ermitteln welche abhängigen SPs es gibt und diese vom Skript ebenfalls neu compilieren lassen.

Das versuche ich ja zu vermeiden. Das kann ein ganzer Baum sein :(

Ist doch egal, ob das Update ein Bisschen länger dauert.

Gibt es die Möglichkeit (ein Kommando für ein Script) ohne den code nochmal in das script aufzunehmen. Weil der aktuelle code ist ja schon ind er DB.

[mkinzler]

Ich würde bei einem Update eine neue, bis auf die SPs leere Db mitliefern und dann die Daten von der alten in die neue DB übernehmen.

[MyRealName]

Zitat:

Zitat von mkinzler (Beitrag 1260759)

Ich würde bei einem Update eine neue, bis auf die SPs leere Db mitliefern und dann die Daten von der alten in die neue DB übernehmen.

Mach das mal, da killen dich die Kunden. Besonders die, die millionen von Datensätzen haben in den Transaktionstabellen wie Inventar oder Buchung. In unserem Fall reden wir von einer DB mit 800+ Tabellen. Und wir haben Kunden mit mehreren Dbs, einer hat sogar 130. Wieviele Tage soll denn der da warten ? :D

[Neumann]

Ändere schon ab und zu Stored Proc. in Firebird - Recompile musste ich noch nie machen. Ich kopiere einfach den DDL-Script in eine TIBCScript-Komponente (IBDAC) und lass den Script dann bei Bedarf ausführen.

Übrigens der Link zu den Komponenten http://www.maf-components.com funktioniert nicht, kommt Forbidden

[Dejan Vu]

Ich würde mir ein Synchronisationstool anschaffen, d.h. ein Tool, das ein Skript generiert, damit eine Datenbank mit Schema 'A' in eine Datenbank mit Schema 'B' umgewandelt wird, ohne die Daten zu zerstören.

Für SQL-Server verwende ich die Redgate-Tools, aber die haben sich eben auf SQL-Server eingeschossen.

[MyRealName]

Das Problem hängt mit dem internen Cache von Firebird zusammen. Wenn Proc A eine Proc B aufruft, dann wird die in den cache geladen wenn Proc A ausgeführt wird. Wird Proc B geändert und neu compiliert, müsste Firebird den Cache leeren oder zumindest diese Proc B entladen oder neu laden, tut er aber nicht. Da hilft nur die Proc A zu übersetzen opder Firebird neu starten im Moment.

Das Problem ist schon seit 2009 bekannt, aber offensichtlich noch nicht gelöst (obwohl IMHO ein Quick'n'Dirty fix könnte sein dass man einfach den cache leert oder dass man ein Kommando im script schicken kann, der das tut).