Firebird 2.1 Migration

Leider ist es unter Umständen nicht so einfach, Anwendungen zum Laufen zu bringen, die unter Windows laufen.

Bisher einschließlich zur Version war das Vorgehen einfach:
1. EXE in ein Verzeichnis
2. fbclient.dll in das selbe Verzeichnis
3. firebird.msg ebenfalls in das selbe Verzeichnis legen

Und dann: Starten fertig.

Bei vielen Installationen wird das auch mit fbclient.dll von Firebird 2.1 klappen, aber nicht auf allen Rechnern.

Lösung: Auch bei Firebird 2.1 nur die Client-lib von Firebird 2.0 verwenden.

Damit klappt der Verbindungsaufbau gut aber man verzichtet auf die Vorteile des erheblich beschleunigten Netzwerk-Protokolls von Firebird 2.1

Wichtig ist eine passende Client-lib aber auf alle Fälle, wenn Sie das lokale Protokoll (Verbindung ohne Angabe von Servernamen) unter Windows verwenden wollen.

Alternativ: Auf Clients mit Problemen einfach das Server-Setup aufrufen und nur die Client-Komponenten lokal installieren oder einfacher von Microsoft die entsprechenen Bibliotheken herunterladen:
http://www.microsoft.com/downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=de

Monitoring Tables: Was geschieht gerade?
Einen Überblick über die aktuell implementierten Monitoring-Tabellen gibt es im Firebird Wiki:

https://wiki.firebirdsql.org/wiki/index.php?page=Monitoring+tables

Wichtig hierbei:
Die SQL-Statements gegen die Monitoring Tabellen müssen als SYSDBA oder als Besitzer der DB (Wenn wir einen Firebird DB anlegen, dann sind immer die Webmaster-Accounts Besitzer der Datenbank) ausgeführt werden.

Als regulärer User hat man keinen Zugriff auf die Monitoring-Tabellen bzw. nur auf eigene Objekte.

Einen ersten Überblick, welche Informationen man aus den Monitoring-Tabellen erhalten kann, gibt auch der Wiki-Eintrag.

Die Alias-Überprüfung wurde verschärft.

In Firebird 1.5 gingen solche “unsauberen” Konstrukte durch:

CREATE OR ALTER TRIGGER FAUINV_BESTELLUNG_BIU10 FOR FAUINV_BESTELLUNG
ACTIVE BEFORE INSERT OR UPDATE POSITION 10
AS
DECLARE VARIABLE "TempNummer" VARCHAR(84);
begin
  SELECT UPPER(I."Kurz") FROM FAU_INSTITUT I 
    WHERE I."Id" = FAUINV_BESTELLUNG."RefBestInst"
  INTO :"TempNummer";
end

Firebird 2.1 möchte die Formulierung aber sauber:

CREATE OR ALTER TRIGGER FAUINV_BESTELLUNG_BIU10 FOR FAUINV_BESTELLUNG
ACTIVE BEFORE INSERT OR UPDATE POSITION 10
AS
DECLARE VARIABLE "TempNummer" VARCHAR(84);
begin
  SELECT UPPER(I."Kurz") FROM FAU_INSTITUT I 
    WHERE I."Id" = NEW."RefBestInst"
  INTO :"TempNummer";
end

In Firebird 1.5. durfte man eine Referenz auf die Tabelle, in deren Kontext ein Trigger ablief, einfach direkt bezeichnen.
Firebird 2.1 überprüft das sauberer!

Analog gilt dies auch für Tabellen und Aliase:
Folgende Abfrage läuft unter Firebird 1.5 prima:

SELECT UPPER(I."Kurz"), B."Datum" FROM FAU_INSTITUT I
JOIN FAUINV_BESTELLUNG B ON FAUINV_BESTELLUNG."RefBestInst" = I."Id"

Firebird 2.1 quitiert solche Abfragen aber mit
SQL error code = -206.
Column unknown.
FAUINV_BESTELLUNG.RefBestInst.
At line 2, column 29.

Besser also immer:
SELECT UPPER(I."Kurz"), B."Datum" FROM FAU_INSTITUT I
JOIN FAUINV_BESTELLUNG B ON B."RefBestInst" = I."Id"

Ab sofort gibt es im Blog ein neues Themen-Gebiet: “Firebird 2.1 Migration”

Hier werden wir kleine “Fallen” auflisten, über die wir bei der Migration unserer Projekte nach Firebird 2.1 gestolpert sind.

Das Meiste oder gar alles kann man auch den Release-Notes entnehmen, aber wir wollen die Punkte hier – soweit möglich – mit einem Beispiel und in Deutsch auflisten.

Gerne nehmen wir auch Hinweise und Punkte von Anwendern hier auf!

Noch ein Hinweis: Unsere Datenbanken laufen derzeit meist unter Fireibrd 1.5, so dass viele Punkte auch bei der Migration von 1.5 auf 2.0.X auftreten können.