[Firebird] Stored proc recompile

[mkinzler]

Zitat von MyRealName:

Zitat von mkinzler:

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 von mkinzler:

Zitat von MyRealName:

Zitat von mkinzler:

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 von 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.

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 ?

[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).