In Firebird Blob-Text-Felder mit UTF-8 schreiben

[TheMiller]

Hallo,

bin fast am Durchdrehen und bekomme so langsam das Gefühl, als ab Firebird der letzte Mist ist. Seit Anfang an habe ich hier und da Probleme mit FB und Bugs tauchen auf. Nunja.

Momentan versuche ich, in ein Blob-Feld (Blob, Sub_Type Text, Segment Size 80, UTF-8) einen einfachen String wie zB "ääää" zu schreiben. Gespeichert wird immer nur "????".

In VarChar-Felder funktioniert das alles richtig. Einen Blob möchte ich dann später dafür benutzen, ganz lange Texte zu speichern.

Mein Connect sieht so aus:

Delphi-Quellcode:

Connection.SpecificOptions.Values['Charset'] := 'UTF8';
Connection.SpecificOptions.Values['UseUnicode']:='True';
Connection.SpecificOptions.Values['EnableMemos']:='True';
Connect();

Und speichern geschieht auf folgendem Weg. Wobei ich schon mit "DataType" (ftBlob, ftMemo, ftWideMemo) gespielt habe:

Delphi-Quellcode:

if (fParameter[i].datatype = 'Blob') then
begin
  Query.ParamByName(fParameter[i].fieldname).DataType:=ftBlob
  Query.ParamByName(fParameter[i].fieldname).AsString:=fParameter[i].value;
end;

Könnt ihr mir bitte einen Tipp geben? Und vor allem: Ist Firebird wirklich so schlecht, wie ich mittlerweile das Gefühl habe, oder gehe ich damit nur falsch um? Oder hätte ich vielleicht besser bei MySQL (embedded) bleiben sollen?

Danke im Voraus!

[haentschman]

Hallo...

willst du richtiges Unicode ? Oder nur ÄÜ... usw. Bei letzterem reicht es den Zeichensatz of NONE zu lassen. Für ersteres hilft vieleicht das http://ibexpert.net/ibe/index.php?n=...tionsToUnicode weiter.

:hi:

Zitat:

Oder hätte ich vielleicht besser bei MySQL (embedded) bleiben sollen?

FB ist aus lizenztechnischen und vieeeelen anderen Vorzügen die bessere Wahl. Wechsle auch mal auf 2.5... besser

[himitsu]

Bezüglich der kranken Lizenzbedingungen vom MySQL gab es schon mehrere Thread,
diese solltest du hier im Forum mal suchen.

So wie ich das verstanden hab, ist das leider kaum nutzbar, jedenfalls nicht kostenlos oder du kaufst dir eine entsprechende "günstige" Lizenz.

[TheMiller]

Hallo.

Danke für die Antworten. Dann nehme ich von MySQL erstmal Abstand.

Zu dem Unicode-Problem:

Also eigentlich wollte ich damals bei Beginn des Projekts volle Unicode-Unterstützung, da es einfach die Zukunft ist und keine weiß, was sie so bringt. Daher gleich von Anfang an Unicode. Deswegen würde ich das gerne weiter so durchziehen.

Die Datenbank habe ich leider nicht mit "default character set UTF8" erstellt, sondern dazu - glaube ich - nichts angegeben. Ich habe sie über ein Programm erstellt und immer, wenn ich nach Character Set gefragt wurde, habe ich UTF8 genommen.

Habe jetzt auch getestet: All meine VarChar-Felder sind wirklich echtes UTF8. Ich kann aus der Windows-Zeichentabelle alle Unicode-Zeichen eintragen - sie werden richtig gespeichert, stehen in der DB richtig und werden auch wieder richtig angezeigt.

Erstelle ich ein Blob-Feld (Subtype text) CS UTF8, dann werden bei Unicode-Zeichen nur "???" gespeichert. Warum? Ich schätze dann mal, dass es nicht an der Datenbank(-Definition), sondern entweder der Version (2.1) oder an der Verbindung (UniDAC) liegt.

Reicht es für ein Update der DB aus, das neue Paket zu laden und die Daten einfach zu ersetzen, oder muss ich noch Queries in der DB dazu ausführen?

Auch habe ich noch eine Frage zu den Blobs generell. In den Links, die ihr gepostet habt, steht folgender Satz drin:

Zitat:

And simply replacing your large VARCHARs with blobs is not necessarily the solution. Every time you change it, the versions are stored in the memory which can have a huge negative impact on server performance. So if you do work with variables that are blobs, do not manipulate them too often. Or alternatively work on VARCHAR variables and combine them in the last step to a single blob.

Ich kann zwar gut Englisch, aber das verstehe ich nicht ganz (vom Sinn her). Heißt dass, das jede Änderung eines Blob-Wertes gespeichert wird? Das wäre ziemlich schlecht, da ich all meine Datensätze (RTF-Format) in Blobs speichere. Keine RTF-Dokumente, aber RTF-Format. Oder bezieht sich das nur auf Änderungen an dem Felder (ALTER TABLE....)?

Danke!

[Uwe Raabe]

Zitat:

Zitat von DJ-SPM (Beitrag 1161817)

Zitat:

And simply replacing your large VARCHARs with blobs is not necessarily the solution. Every time you change it, the versions are stored in the memory which can have a huge negative impact on server performance. So if you do work with variables that are blobs, do not manipulate them too often. Or alternatively work on VARCHAR variables and combine them in the last step to a single blob.

Ich kann zwar gut Englisch, aber das verstehe ich nicht ganz (vom Sinn her). Heißt dass, das jede Änderung eines Blob-Wertes gespeichert wird? Das wäre ziemlich schlecht, da ich all meine Datensätze (RTF-Format) in Blobs speichere. Keine RTF-Dokumente, aber RTF-Format. Oder bezieht sich das nur auf Änderungen an dem Felder (ALTER TABLE....)?

Ich denke, das bezieht sich auf die MGA (Multi- Generational Architecture) von Firebird, die dafür sorgt, daß jede Transaktion mit der passenden Version der entsprechenden Datensätze arbeitet. Wenn nun häufig Änderungen an den Inhalten von BLOB-Feldern vorkommen, dann verbraucht das naturgemäß auch mehr Speicher. Ob das relevant ist, kann allerdings nur die Praxis zeigen.

[haentschman]

Hallo...

Zitat:

Reicht es für ein Update der DB aus, das neue Paket zu laden und die Daten einfach zu ersetzen

2.1 und 2.5 unterscheiden sich im Filesystem. Eine 2.1 DB ist auch unter 2.5 lauffähig, nicht umgekehrt.
Tipp:
- via IBExpert alles aus 2.1 extrahieren (Metadaten und Daten)
- DB 2.5 erstellen
- Script wieder einlesen

...fertsch. 8-)

[jobo]

MGA:
http://www.firebirdfaq.org/faq44/

Zitat:

multiple versions of records are kept in the database as long as at least one transaction needs them.

Ich arbeite nirgendwo produktiv mit FB, aber m.E. ist das nur eine von mehreren Techniken mit denen RDBMS das Transaktionshandling machen.
So oder so, alle diese Techniken brauchen Speicherplatz, um offene Transaktionen zu verwalten und bei Bedarf (ältere Transaktionen oder Rollback) den Zugriff auf die (noch nicht commiteten) Daten zu gewährleisten.

Also deswegen kein Grund zur Panik.

Wo tritt die falsche Wiedergabe der Umlaute auf? Ist das vielleicht nur im Delphiprogramm? Schau mal, ob der Font, den Du verwendest für UNICODE / UTF 8 geeignet ist.

Ansonsten würde ich heutzutage nur SingleByte Design verwenden, wenn ich 500% sicher bin, dass es nie anders benötigt wird. Insofern UTF8 = Standard.
Mit Single Byte sparst Du dann vlt die Hälfte bis 2/3 Speicherplatz für Texttypen, wenn es hoch kommt.
(ok, kommt auch drauf an, mit welchen OS/Frontend man alles zugreift, aber das sollte selbst bei alten 32 bit Systemen über die DB Treiber zu regeln sein)

[TheMiller]

Ich wurde irgendwie nicht über die neuen Antworten benachrichtigt... deshalb etwas späte Reaktion.

Also das mit dem Update ist ja schonmal ziemlich schlecht. Das Programm läuft schon Produktiv bei vielen Leuten. Ich muss das also irgendwie alles automatisieren.

UTF8 soll auch bei mir Standard bleiben. Deswegen mach ich ja diese Aktion. Die Werte stehen schon falsch in der Datenbank drin. Dies gilt aber nur für die Blob-Felder, nicht für die Varchar-Felder. Da ist alles absolut richtig und Unicode.

Es muss also entweder an der DB-Komponente liegen (ich benutze UniDAC und habe trotz Update keine Besserung gesehen) oder es liegt an Firebird selbst.

Ich habe ja oben geschrieben, wie ich die Daten abspeichere - das scheint ja ok zu sein.

Habt ihr noch Ideen?

[TheMiller]

Ach sorry: Nochmal zum Update - ich liefere die Software mit Firebird embedded aus. Gilt dafür die gleiche, oben genannte Vorgehensweise?

Ich suche nebenbei in Google und poste eine Lösung, wenn ich sie finden sollte.

[TBx]

Mir sind Unicodeprobleme bei IBDac in Verbindung mit Lazarus bekannt.
Da die entsprechenden IBDac-Quellen wohl in UniDac enthalten sein dürften, vermute ich den Fehler in der Komponente.

Gruß

Thomas

[RSF]

Ich überlege seit einiger Zeit auch das nächste Projekt mit Firebird zu erstellen.
z.B. aus lizenztechnischen Gründen.
Aber wenn ich solche und ähnliche Probleme lese, scheue ich die Umstellung und
bleibe bei Advantage Database Server. (Localserver ist kostenlos. ADS natürlich nicht)

[TheMiller]

Zitat:

Zitat von TBx (Beitrag 1161940)

Mir sind Unicodeprobleme bei IBDac in Verbindung mit Lazarus bekannt.
Da die entsprechenden IBDac-Quellen wohl in UniDac enthalten sein dürften, vermute ich den Fehler in der Komponente.

Das wäre ja noch viel schlechter... Es muss doch möglich sein, einen UTF8-String in einem Blob zu speichern :roll:
Wenn es wirklich an den UniDACs liegt, dann bin ich wirklich schlecht gelaunt. Zumal habe ich gestern die allerneueste Version installiert (nebenbei: selbst dabei gab's wieder Probleme) und zum anderen: günstig sind sie ja jetzt auch nich gerade. Nunja.

Ich konnte leider noch keine weiteren Tests machen. Der Fehler besteht also immernoch. Ich werde dann mal ein DB-Update machen.

[mkinzler]

Wenn die Daten schon fehlerhaft in den Blob geschrieben wurden, bringt auch ein Update des Servers/Clients nichts mehr. Schau dir mal an, was genau im Feld der DB steht

[TheMiller]

Stimmt. Aber da habe ich Glück. Das Blob-Feld soll mit einem Programmupdate neu eingeführt werden. Der Fehler tritt also quasi noch in der Entwicklung auf.

Das andere Blob-Feld, das ich benutze macht keine Probleme, da es RTF speichert und die Sonderzeichen maskiert werden, wie ich das gesehen habe. Dieses Feld ist schon immer in der DB und demnach auch schon "ausgeliefert".

Ich fange jetzt an mit Backup/Restore und schau dann mal, wo der Fehler liegt.

Danke

[TheMiller]

So,

habe jetzt ein Backup der alten DB gemacht, eine neue per Script erstellt und die Daten dann wieder importiert. Der gleiche Fehler tritt wieder auf. Kann es wirklich an den UniDACs liegen? Hier mal meine Vorgehensweise:

-------
Backup via gbak.exe
gbak.exe -b -g -z -v -i -IG -user SYSDBA test.db test.db.bak

Umbennen test.db -> test_tmp.db (nur, damit ich zur Not auf sie wieder zurückgreifen kann)

Neue DB erstellen via SQL-Query:
CREATE DATABASE ''test.db'' USER ''sysdba'' PASSWORD ''1234'' PAGE_SIZE 4096 DEFAULT CHARACTER SET UTF8

Restore via gbak.exe
gbak.exe -R o -v -user sysdba -password 1234 test.db.bak test.db

Neues Feld erstellt via SQL-Query:
ALTER TABLE test1 ADD PLAINTEXT BLOB SUB_TYPE TEXT;
-------

So, in alle Felder den gleichen Unicode-String eingetragen und in den VarChar-Felder das richtige Ergebnis erhalten. Beim Blob wieder nur "????"

Im Anhang habe ich die Felddefinition aus DBExpert angehängt. Ich bin ratlos.

Vielen Dank

[Bernhard Geyer]

Zitat:

Zitat von RSF (Beitrag 1161941)

... (Localserver ist kostenlos)

Dann lies mal die Lizenzbedingungen genau durch. Der Localserver ist nicht in allen Fällen kostenlos!

[olaf]

Hallo,

Query.ParamByName(fParameter[i].fieldname).AsString:=fParameter[i].value;

Nehm mal AsMemo statt AsString.

olaf

[tsteinmaurer]

Ich verwende in einem Unicode-fähigen Delphi-Client mit Firebird 2.5 nicht UniDAC, sondern IBDAC, aber dort klappt das Speichern von Unicode mit TParam.AsMemo ohne Probleme.

[TheMiller]

Danke an alle, insbesondere an olaf und tsteinmaurer,

ich habe heute Nacht herausgefunden, an was es gelegen hat. Ich hatte sogar zwei Fehler. Einmal habe ich DataType als ftBlob deklariert und dann eben noch mit asString gespeichert.

Ich kann bestätigen, dass es funktioniert, wenn man AsMemo benutzt. Ich stelle später, wenn ich wieder an der Delphi-VM sitze, den korrekten Quelltext online - eigentlich sind's ja nur ein paar Zeilen, aber der Vollständigkeit halber. Vllt. hat ja jemand mal wieder so ein Problem.

Danke, es funktioniert ;) :thumb: