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

[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

[TheMiller]

Zitat von 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.

Das wäre ja noch viel schlechter... Es muss doch möglich sein, einen UTF8-String in einem Blob zu speichern
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

[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)

[Bernhard Geyer]

Zitat von RSF:

... (Localserver ist kostenlos)

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