Bzgl. Authentifizierung wurde in Firebird 3 die neue "SRP" (Secure Remote Procedure) Methode eingeführt, die auch der Default ist. D.h. sofern du nichts anderes in firebird.conf einstellst, ist diese Art von Authentifizierung aktiv. Hier ist schon mal wichtig zu wissen, dass aus Client-Sicht (z.b. isql oder auch deiner Anwendung) ein Login nur mit der fbclient.dll aus Firebird 3 möglich ist. Mit der Firebird 2.5 Client Library wird das nicht funktionieren. Dazu müßte man auf der Serverseite in firebird.conf den Legacy Modus bzgl. Authentifizierung aktivieren, mit den bekannten Limitierungen wie z.b. nur die ersten 8 Buchstaben des Passworts werden evaluiert etc. Firebird 3 Server vs. 2.5 Clientbibliothek war vielleicht schon mal ein Stolperstein bzw. Unterschied bei deinen Versuchen ...
Die zweite Sache ist, das bei der ZIP Distribution kein SYSDBA User ausgeliefert wird, sondern die Security-
DB leer ist. Somit klappt ein Login mit der Servervariante (d.h. nicht Embedded) nicht. Es muss ein SYSDBA User angelegt werden. Darum auch die Vorgehensweise in den Release Notes auf Seite 115. Wichtig hier ist, dass
KEIN anderer Firebird Serverprozess, egal welcher Version, bei dieser Initialisierung läuft. Somit ist sichergestellt, dass der Connect mit isql über Firebird 3
Embedded erfolgt. Dies wiederum stellt sicher, dass der SYSDBA User mit der SRP Methode angelegt wird. Das Ganze ist vielleicht Stolperstein 2.
Dann gibt es noch eine dritte Sache: Praktisch kann für jede Datenbank eine eigene Security-Datenbank verwendet werden, obwohl das nicht der Default ist. D.h. initial gibt es wiederum
eine (wie in vorangegangenen Versionen) serverweite Security-
DB security3.fdb, aber in databases.conf (die wiederum die aliases.conf ablöst) kann je
DB-Alias eine eigene Security-
DB angegeben werden. Muss aber nicht. Somit kann man z.b. eine eigene Security-
DB auslieferen, wo sich dann der SYSDBA Account nicht mit anderen Installation am selben Server in die Quere kommen. Ein Anwendungsfall hierfür wäre ein Firebird Shared Web-Hosting auf einem Server. Soll jetzt aber nicht heißen, dass man SYSDBA als Owner der
DB und Tabellen verwenden sollte ...
Das ganze schnell hingeschrieben. Ich hoffe das hilft dir weiter bzw. gibt dir einen Anhaltspunkt warum es einmal nicht und einmal schon funktoniert hat.
LG
Thomas