Zeichensatzproblem nach Datenbankumzug?

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Antworten
yummiweb
Beiträge: 4
Registriert: Mo 28. Okt 2019, 01:55

Hallo liebes Forum,

ich bin neu hier und würde gern mal ein merkwürdiges Problem schildern:

Wir nutzen Firebird seit einigen Jahren im Zusammenhang mit einer speziellen Windowsanwendung (FuCoSys). Die eigentliche Anwendung läuft unter Windows 7 und greift per LAN auf eine FB-Datenbank zu, die von einem Firebirdserver unter macos 10.12 bereitgestellt wird.

Das Zusammenspiel funktioniert seit Jahren ziemlich problemlos, lediglich bei macos Systemupgrades will der Firebirdserver dann manchmal ebenfalls auf eine neue Version gehoben werden.

Nun ist es so, dass wir mit dem Firebirdserver und der Datenbank vom macos System gern auf ein Linux System (CentOS) umziehen würden. Dieses Vorhaben scheint erstmal nicht weiter problematisch, also den Firerbirdserver auf dem Zielsystem installiert, den bisherigen Datenbankordner in den passenden Pfad geschoben und noch die Dateizugriffsrechte korrigiert (sind nun identisch mit denen der Muster-DBs). Der Firebird läuft und lauscht auf seinem Port, soweit so gut.

In der Windowsanwendung dann die neue Serveradresse und den neuen Datenbankpfad eingetragen, damit hätte die Umstellung eigentlich abgeschlossen sein müssen, oder?

Bei der Anmeldung in der entsprechenden Windowsanwendung (Benutzer/Kennwort) gibt es nun aber eine Fehlermeldung, die wir nicht richtig deuten können:

"dmDBConnFB.gryReadTmp:"
"Undefined name."
"CHARACTER SET ISO8859_1 is not installed."
"Fehler-Typ: EFIBInterBaseError, Adresse: 0x007DC77E"
"(TfrmAnmeldung)"

Nun ist uns nicht ganz klar, ob diese Fehlermeldung auf ein Problem mit der Firebird DB oder der Windowsanwendung hindeutet. An der Windowsanwendung hat sich nichts geändert, mit der unter macos bereitgestellten Datenbank läuft sie weiterhin wie gehabt.

Aber auch an der FB-Datenbank hat sich ja nichts geändert, sie läuft halt nur auf einem anderen System auf einer anderem Maschine. Vorher BSD (Mac) und jetzt halt Linux. Daher verstehen wir insbesondere den Hinweis bzgl. "CHARACTER SET ISO8859_1 is not installed." nicht so richtig. Meines Erachtens dürfte doch der in der Datenbank enthaltene Zeichensatz sich nicht ändern nur weil der Firebirdserver auf ein anderes System wechselt, oder doch? Ich meine, beim anlegen einer neuen Datenbank mögen ja evtl. Voreinstellungen eine Rolle spielen, aber hier handelt es sich doch um eine bestehende Datenbank.

Ach so, die Übertragung der DB erfolgte bei deaktiviertem FB-Server, ausserdem haben wir sie testweise auf verschiedenen Wegen übertragen, per SCP, RSYNC und SMB.

Vielleicht hat ja jemand von euch eine Idee, ich bin für jeden Hinweis dankbar.

Hier noch ein paar Zusatzinfos:
Alter Server: macos 10.12 mit FirebirdSuperserver ("FirebirdSS-2.5.8-27089-1-lipo-x86_64")
Neuer Server: CentOS 7 System mit Firebird-Superserver aus dem Standard-Repo ("firebird-superserver.x86_64 2.5.8.27089.0-1.el7")

Ordnerrechte des entsprechenden Datenbankordners auf dem Linux System "/var/lib/firebird/data/fucosys" sind: "drwxr-x- - - firebird firebird"
Berechtigungen der eigentlich Datenbankdatei (analog zum Template "employe.fdb") lauten: " -rw-rw- - - firebird firebird"

Gruss yummiweb
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Bei der Erstellung einer DB wird der CHARSET für Char/Varchars definiert.
Für die Datenumsetzung bedarf es einer Umsetztabelle, die i.d.R. im "intl"-Verzeichnis steht. Dort gibt es eine .Conf sowie die .dll.
Wenn du nun aus dem Programm heraus mit einem anderen CHARSET verbindest (z.B. mit Win1252) muss eine Codeumsetzung erfolgen.
yummiweb
Beiträge: 4
Registriert: Mo 28. Okt 2019, 01:55

Vielen Dank für deine Antwort, ich verstehe sie jedoch nicht bzw. verstehe ich nicht in welchem Zusammenhang das mit meinem Problem steht.
Bei der Erstellung einer DB wird der CHARSET für Char/Varchars definiert.
Es geht hier um den Zugriff auf eine bereits bestehende Datenbank, d.h. in der DB dürfte entsprechendes bereits definiert sein und im bestehenden Setting (Windows-Client/OSX Firebirdserver) funktioniert es ja auch problemlos. Ich verstehe nicht ganz warum der Zeichensatz in einer DB geändert werden muss nur weil der Firebirdserver auf eine andere Plattform umzieht. Wenn sich wesentliches an der Clientanwendung geändert hätte, wäre das evtl. was anderes..
Für die Datenumsetzung bedarf es einer Umsetztabelle, die i.d.R. im "intl"-Verzeichnis steht. Dort gibt es eine .Conf sowie die .dll.
Siehe oben, am Windows System und der Clientanwendung hat sich nichts geändert.
Wenn du nun aus dem Programm heraus mit einem anderen CHARSET verbindest (z.B. mit Win1252) muss eine Codeumsetzung erfolgen.
Die Clientanwendung hat sich nicht geändert, warum sollte sie also plötzlich Anfragen mit einem anderen CHARSET stellen? Oder warum sollte der Firebirdserver seinerseits mit einem anderem CHARSET antworten? DB ist doch noch dieselbe?

Wo ist MEIN Denkfehler?
Der in der Datenbank zu verwendete CHARSET wird (i.d.R. beim anlegen der DB) innerhalb der Datenbank definiert, richtig? (Teil der DB Struktur)

"Übersetzt" der Firebirdserver etwa seinerseits noch DB Inhalte bzw. dessen CHARSET beim ausliefern an die Clienten?

Gruss yummiweb
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Eingangs sprichst du von einem Umzug auf Linux.
Das war für mich die Umgebungsänderung.

Der Default bei Linux ist wohl ISO8859_1, bei Windows WIN1252.

Welcher CHARSET der Default ist steht in der RDB$DATABASE.
Die Charsets auf Feldebene stehen nach dem Create in den DOMAINS der Felder.
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Hallo yummiweb,

wie wurde die Datenbank übertragen? Per Kopie oder Backup & Restore?

In der Datenbank ist ein Standardzeichensatz eingestellt, z.B. UTF-8. Die Client-Anwendung muss mit dem gleichen Zeichensatz auf die Datenbank zugreifen. Sonst gibt es Kauderwelsch.

Die Meldung zeigt definitiv einen Fehler auf Client-Seite. Bitte prüfe, ob wirklich die korrekte fbclient.dll geladen wird.
Evtl. sind noch Überbleibsel anderer Firebird-Installationen vorhanden, die Schwierigkeiten machen. Diesbezüglich auch mal nach gds32.dll suchen.

Gruß
Martin
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

"In der Datenbank ist ein Standardzeichensatz eingestellt, z.B. UTF-8. Die Client-Anwendung muss mit dem gleichen Zeichensatz auf die Datenbank zugreifen. Sonst gibt es Kauderwelsch."

Dies kann ich so nicht stehen lassen.
Für alle Zeichenfelder greife ich mit String-Variablen zu. Dies sind grundsätzlich UCS2-Variablen.
Der Treiber (ODBC/.NET) und die DB sorgt dann für die automatische Codewandlung. Kauderwelsch hat es bei mir noch nie gegeben, egal ob ich die DB mit UTF8 oder WIN1252 erstellt habe.
yummiweb
Beiträge: 4
Registriert: Mo 28. Okt 2019, 01:55

Vielen Dank für eure Antworten.
wie wurde die Datenbank übertragen? Per Kopie oder Backup & Restore?
Die Datenbank (der Ordner mit den DB Files) wurde vom maxOS (BSD-Unix) auf den CentOS (Linux) Host über das Netzwerk kopiert und zwar versuchsweise per scp, rsync (ohne Zeichensatzkonvertierung) und smb. Testweise habe ich den Ordner auch als ZIP übertragen. Da es also eine einfache Dateiübertragung und kein klassischer Dump/Restore war, kann auf dieser Ebene doch eigentlich auch kein Problem mit den Zeichensätzen (in der DB) entstanden sein, oder?

Da sich nicht der Client sondern nur der ausliefernde Host geändert hat, könnte ich ja noch verstehen wenn hier irgendeine Voreinstellung am Firebirdserver dazwischenfunken würde, bzw. eine solche hier noch angepasst werden müsste. Ich wüsste jedoch nicht wo oder welche. Wo müsste ich nachsehen?

Die Firebirdserver Installation am Mac lief übrigens mit den Standardeinstellungen. Und irgendwie wundert es mich, dass die Standardeinstellungen des Firerbirdserver im BDS Unix des Mac so sehr anders sein sollen als die im Linux. Ich würde die Voreinstellungen auf diesen Systemen gern vergleichen wenn ich wüsste wo ich diese finde.
In der Datenbank ist ein Standardzeichensatz eingestellt, z.B. UTF-8. Die Client-Anwendung muss mit dem gleichen Zeichensatz auf die Datenbank zugreifen.
Das ist mir schon klar. Aber der in der DB (dem DB File) eingestellte Zeichensatz dürfte sich durch das umkopieren doch nicht verändert haben oder?
Die Meldung zeigt definitiv einen Fehler auf Client-Seite. Bitte prüfe, ob wirklich die korrekte fbclient.dll geladen wird.
Davon mal abgesehen, dass ich gar nicht sagen kann ob die Windows-Clientanwendung diese DLLs überhaupt nutzt, verstehe auch nicht, warum sich hier etwas geändert haben soll wenn sich doch "nur" der Server geändert hat und nicht der Client. Wenn ich die Windows-Clientanwendung wieder auf den OSX-Firebirdserver umstelle funktioniert alles wie es soll. Es erscheint mir also auch nicht logisch warum ich auf der Cleintseite etwas ändern soll. Dass ich auf Serverseite irgendetwas anpassen muss ist klar, aber was und wo?

Insgesamt mangelt es mir hier natürlich noch etwas am grundsätzlichen Verständnis und aus euren Antworten lässt sich für mich auch nicht sicher herauslesen, ob jeweils die Server- oder Clientseite gemeint ist, z.B. hier
Der Treiber (ODBC/.NET) und die DB sorgt dann für die automatische Codewandlung.
Daher nochmal meine Frage etwas konkreter:
Liefert der Firebirdserver die Datenbank bzw. deren Inhalte jeweils immer so aus "wie sie sind", also mit genau dem Zeichensatz der IN der DB enthalten bzw. definiert ist?

Oder verändert der Firebirdserver (nicht der Client) die Inhalte beim ausliefern an den Clienten je nach Voreinstellung?

Am Firebirderver kann und werde ich gern alle Änderungen vornehmen die erforderlich sind (ausser an der Datenbank selbst!), aber am Client bzw. der Clientanwendung geht das leider nicht.

Gruss yummiweb
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Guten Abend,
Die Datenbank (der Ordner mit den DB Files) wurde vom maxOS (BSD-Unix) auf den CentOS (Linux) Host über das Netzwerk kopiert und zwar versuchsweise per scp, rsync (ohne Zeichensatzkonvertierung) und smb. Testweise habe ich den Ordner auch als ZIP übertragen. Da es also eine einfache Dateiübertragung und kein klassischer Dump/Restore war, kann auf dieser Ebene doch eigentlich auch kein Problem mit den Zeichensätzen (in der DB) entstanden sein, oder?
Das Kopieren einer DB auf Dateibasis kann zu defekten Datenbanken führen. Neben nicht abgeschlossenen Transaktionen, kann es auch Probleme mit unterschiedlichen Firebird-Versionen (ODS) auf den Systemen (Firebird-Version, Bittigkeit) geben. Ein Umzug sollte immer per Backup & Restore durchgeführt werden. Dies hat aber vermutlich nichts mit dienem beschriebenen Problem zu zun.

bfuerchau hat ja schon einige Dinge bzgl. der Zeichensätze klargestellt.

Die DB hat einen voreingestellten Zeichensatz. Der Treiber nutzt ebenfalls einen Zeichensatz für die Verbindung. Dieser muss identisch mit der DB sein. Damit werden die Daten dann korrekt an die Client-Anwendung übermittelt. Bis hierhin müsste mir bfuerchau zustimmen.

Das reine Kopieren ändert nichts am DB-Zeichensatz. Aber kann der neue Firebird-Server mit dem eingestellten Zeichensatz umgehen? Kennt der diesen? Hast du schon mal in die Logs gesehen? Vielleicht steht dort etwas wichtiges. Bitte probiere auch ein reguläres Backup & Restore durch. Wir werden dem Ganzen schon auf die Spur kommen.

Gruß
Martin
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Da das Thema CHARSET ja bisher keins war, hat die FB wohl mit einem Default gearbeitet.
Dieser Default kann aber u.U. von der OS-Umgebung beeinflusst werden!
Wenn also das OS geändert wird, kann ebenso der default CHARSET ein anderer sein.
Aber schauen wir uns die Fehlermeldung mal an:

CHARACTER SET ISO8859_1 is not installed.

Wie ich oben schon schrieb, im Verzeichnis der FB-Installation muss ein Ordner "intl" (International) vorhanden sein, der alle Charsets der FB enthält, damit entsprechende Codewandlungen und Sortierungen durchgeführt werden können. Prüfe deine Installation mal darauf.

Bitte prüfe daher auch noch mal:
Was steht in der RDB$DATABASE als Default-Charset?
Wie genau sieht dein Connectionstring an die FB aus?
Welche CHARSET's stehen in deinen DDL's für deine Tabellen und auch für die Zeichenfelder RDB$RELATIONS?
Und zu guter letzt: Welche Default-Codepage wird auf deinem Host gefahren?

Selbst wenn NONE für die Charset's verwendet wird, so muss auf jeden Fall der SQL-String selber in eine korrekte Codepage gewandelt werden.
yummiweb
Beiträge: 4
Registriert: Mo 28. Okt 2019, 01:55

Das Problem wurde inzwischen gelöst, indem eine andere Firebird Variante verwendet wurde. Mit dem Firebird "SuperClassic" (hier unter CentOS 7) funktioniert der Zugriff unter Windows jetzt einwandfrei und ohne diese Fehlermeldung.

Der Lösungsansatz wurde gefunden in einem anderen Forum, wo ein Ähnliches Problem beim Zugriff von einem Windows System beschrieben wurde. Dem Beitrag nach liegt der Fehler wohl in der letzten verfügbaren Firebird SuperServer Version aus der 2.5 er Reihe, die nach Supportende dann wohl nicht mehr fehlerbereinigt wurde.

Gruss yummiweb
Antworten