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.

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 von DJ-SPM:

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.

[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