Migration von Firebirdprojekt (Delphi 2006 nach delphi 2009)

[FlatCoder]

Hallo zusammen,

ich weis, es wurde schon so oft über UTF8 und Konvertierungsmöglichkeiten diskutiert.
Ich weis auch nicht, ob mein Fall neu ist oder ob ich bei Delphi 2006 bleioben MUSS weil es einfach nicht mehr funktioniert:

In einem betrieblichen Projekt habe ich UNICODE Zeichen nach Firebird 2.1 gespeichert.
Dazu verwendete ich eine Anwendung die in Delphi 2006 geschrieben war.
Gespeichert habe ich mit den TNT Komponenten (da WideString) und der Funktion UTF8Encode(<Variable>).
Dies ist auch wunderbar und mein FirebirdMaestro stellt mir alles sauber dar.

Zum dekodieren benutzte ich die Methode UTF8Decode(<Feldname>), um wieder alles in der TNTEdi darzustellen.

Nun bin ich vor einer ganzen Weile auf Delphi 2009 umgestiegen und die TNT Komponenten sollen ja um Himmels
Willen nicht mehr verwendet werden (Wegen WideString usw.)

Nun versuche ich, die Schriftzeichen wieder auszulesen und verwende (da nicht anders möglich) die Funktion:
UTF8ToString(<Feld>)

Die meisten Felder übernimmt er auch wunderbar und ich freute mich schon bis ich sah:
Bestimmte Felder, die ebenfalls UNICODE_FFS Formatiert sind (in Firebird) und EBENFALLS
mit UTF8Encode gespeichert wurden, werden fehlerhaft eingelesen. Es werden einfach Zeichen VERSCHLUCKT.
Ich weis echt nicht mehr weiter...
In Delphi 2006 macht er es ANSTANDSLOS mit der Funktion UTF8Decode. In Delphi 2009 tritt das genannte problem auf,
aber man soll ja UTF8Decode nicht mehr nehmen. Aber egal ob ich UTF8Decode oder UTF8ToString verwende,
Delphi 2009 verschluckt bei manchen Feldern einfach die Zeichen...

Wäre nett wenn jemand einen Tipp hätte, ansonsten arbeite ich beim alten Projekt mit der "alten" Version und neue
Projekte werden dann ohnehin mit Delphi 2009 gemacht, was aber laut Updatelizenzrecht nicht sein darf...
Die ganze Anwendung mit über 100.000 Programmzeilen möchte ich nicht unbedingt komplett von neuem beginnen
und die Datenbank ist mittlerweile so groß geworden, dass ich da nicht einfach irgendwie "migrieren" kann.

Naja bin gespannt auf eure Antworten.
Benötigt ihr Zeichenbeispuele und die Ergebnisse? Wenn ja lasst es mich wissen.

Bis dann

Ingo

[mkinzler]

Zitat:

was aber laut Updatelizenzrecht nicht sein darf...

Solange du nicht gliechzeitig mit beiden arbeitest, dürfte das kein Problem sein.
Du könntest auch einmalig die Werte in det Datenbank fixen

[Elvis]

War Unicode_FSS überhaupt UTF8?
Wenn ich mich recht entsinne war das UCS2 (der Unicode-Dialekt, der von Widestring "gesprochen" wird)
UTF8 ist im ASCII-Bereich nicht von ASCII zu unterschieden. Allerdings beanspruchen Zeichen außerhalb des ASCII-Bereiches mehrere Bytes.
UCS2 hingegen nutzt immer 2 Bytes pro Zeichen. Seit Win2000 nutzt Windows Utf16, das bei ausgefalleren Zeichen auch Surogate pairs nutzt. (Dann: 4 Bytes pro Zeichen!)
Delphis neuer UnicodeString ist Utf16 und für einen sehr großen Zeichenbereich kompatibel mit UCS2.

Der große Unterschied ist das BOM. Bei UTF8 ist die Byteorder fest vorgeschrieben, braucht also kein BOM, und deshalb ist es ASCII-kompatibel.
UCS2 hat vorne ein BOM, welches sagt wie herum Words ablegt werden (Big/Little Endian)


Firebird ist was Charsets angeht allerdings ziemlich grauenvoll. Der Client ist nicht in der Lage Charsets zu übersetzen, was bei mir schon zu einigem sinnlosen Ärger führte.

[FlatCoder]

Danke für eure Antworten.
Das mit dem "Fixen" der Daten geht nicht so einfach. Sobald ich versuche den reinen UnicodeString zu schreiben (Delphi 2009 ohne Konvertierung) verhält es sich wie mit dem "alten" Delphi. Aus den betreffenden Zeichen wird ein Fragezeichen. Alles also für die Katz. Ich lasse das Projekt auf der alten Version und werde neue Datenbankprojekte mit einer anderen Datenbank oder anderer Konvertierungsmethode machen. Hab noch keine Ahnung wie.
Normalerweise sollte es ja reichen, wenn ich hergehe, Unicode schreibe und Unicode lese und das wars. Ohne Konvertierung etc.

Naja mal schauen was die "ach so super angepriesene" Delphi 2009er Version noch so auf Lager hat um mich in Schach zu halten

Danke nochmal!

[tsteinmaurer]

Hallo,

UNICODE_FSS ist eine alte Krücke und hat(te) so manche Probleme. Darum wurde das INTL Modul in Firebird 2 komplett überarbeitet mit dem Ergebnis eines neuen Zeichensatzes UTF8. Ich würde das Ganze mal an einer neuen Datenbank mit UTF8 (nicht UNICODE_FSS) und Delphi 2009 ohne irgendwelche eigenen Konvertierungsmaßnahmen ausprobieren.

[FlatCoder]

Das werde ich mal machen das stimmt. eine neue Datenbank und dann UTF8. Ich ging damals davon aus (so habe ich das mitbekomen und gelesen) dass UNICODE_FFS der beste geeignete Datentyp wäre. Aber das mit dem UTF8 werde ich probieren. Damals war das Thema noch Neuland für mich und UNICODE_FSS hörte sich plausibler an als UTF8
Und so wuchs und wuchs der Datenbestand bis heute an. Exportieren nach EXCEL könnte ich es ohne Probleme und auch wieder nach Delphi importieren um es danach neu in die DB zu schreiben. Das wäre nciht die Sache, ein Konvertierer wäre schnell passiert.

Ich werde meine Tests machen wenn ich dazu komme und mich dann nochmal melden denn ich denke nicht, dass es nur MEIN Problem ist?

[FlatCoder]

Eine Frage hätte ich noch...

Ich verwende ja die UIB Components, auch noch unter D2009.
Ich weis, man soll sich da nicht so festlegen oder halt rumprobieren aber habt Ihr schon Erfahrungen mit "guten" Alternativkomponenten gemacht? Können auch kommerziell sein!

Gehört habe ich gutes von:

ZEOS (OpenSource)
IBObjects (Kommerziell)
FIBPlus (Kommerziell)

Wie sind eure Erfahrungen oder greift Ihr mit der Delphieigenen Möglichkeit zu?

Danke nochmal!

Ingo

[mkinzler]

-Für Zeos gelten bestimmte Beschränkungen ( kein harter Commit, ...)
-IBObjects wird auch nur sehr zögerlich weiterentwickelt
-Blieben also nur noch FIBPlus und IBDAC

[FlatCoder]

Hallo zusammen,

ich dachte ich teile es euch mit.
Ich habe eine Lösung für mein UNICODE_FSS Problem und den verschluckten Zeichen bei der Funktion UTF8Decode gefunden.
Wenn es von Interesse ist, schreibe ich gerne wie, wobei ich noch ein paar Tests machen muss, sieht aber gut aus.

Bis dann

Ingo

[mkinzler]

Da andere vielleicht das selbe Problem haben bzw vielleicht noch bekommen, wäre der Lösungsweg interessant