Hi!

Hallo erstmal, dies ist mein erster Besuch in diesem Forum.

Ich verzweifle an folgendem Problem, vermutlich habe ich ein Brett vorm Kopf:
Es soll aus einem TRichedit-Feld der RTF-formatierte Text in einem Textfeld der Postgres-DB gespeichert werden. Dafür muss ich ja auf zwei Sonderzeichen achten: Backslash \ und Hochkomma '. Beides kann ich mit Backslashes maskieren. Jetzt kommt der verzwickte Teil:
Ein Umlaut in RTF-Code sieht beispielsweise so aus: \'e4
Das müsste ich für das Insert-Statement so umschreiben: insert ... values ('\\\'e4')
Soweit klappt das auch, wenn ich über das PGAdmin-Tool nachschaue, steht in der Tabelle exakt \'e4.
Aaaaber:
Sobald ich den Text wieder auslese, bekomme ich das Sonderzeichen für 1/4 gefolgt von der 4. Irgendwo auf dem Weg aus der Tabelle wird der String bereits wieder interpretiert und der Backslash wird zu einem Sonderzeichen umgebaut. (Pikanterweise liest PGAdmin den Wert korrekt aus). Um den Wert also korrekt in Delphi zu bekommen, müsste ich die Backslashes doppelt maskieren, damit beim Zurücklesen der Backslash erhalten bliebe, also insert ... values ('\\\\\'e4')
Damit bekomme ich aber wieder Probleme mit den Rave-Reports.
Da muss es doch eine einfachere Lösung geben, oder? Ich kann vor lauter Backslashes schon kaum noch geradeaus schreiben

Danke im Voraus!

Dirk

Update: Gerade habe ich festgestellt, das dieses Verhalten nur Daten in DB-Textfeldern betrifft, nicht Varchars. Ich habe da den TStream im Verdacht, der in den DB-Komponenten zugange ist. Leider hilft mir diese Erkenntnis noch nicht weiter...

Zwei Fragen habe ich zuerst mal:

1) wie greifst du auf die PostgreSQL zu?
2) welchen Typ hat dein Datenbankfeld?

Grüße
Mikhal

Ooops, ich habe da wohl ein paar Angaben im Stress vergessen...

Ich benutze die Zeos-Komponenten V. 6.0.12 für den direkten Zugriff unter Delphi 2005. Das Datenbankfeld hat den Typ "Text", der bei Postgres für beliebig lange Texte steht.

Ich kann jetzt nur für die Komponenten von Microolap (PostgresDAC) sprechen: Dort wird die Maskierung für den Typ ByteA von der DataSet übernommen. Hast du schon einmal versucht, ob die ZEOS (ich kenne sie nicht besonders) das auch machen? Die Reaktion beim Auslesen läßt ja darauf schließen.

In der Dokumentation zum Character-Type text bei PostgreSQL 8.0 steht allerdings nichts davon, daß die beiden Zeichen maskiert werden müssen (ich habe jedenfalls nichts dazu gefunden), die Maskierung wird lediglich für den Typ ByteA beschrieben.

Grüße
Mikhal

ByteA ist aber als Binärdatenblock definiert, während Text ein wirklicher Text-String ist. Die Doku zu Postgres gibt an, dass der Unterschied darin besteht, dass auf "Text" die locale-Einstellungen der SPrachumgebung angewendet werden, auf ByteA nicht. Vermutlich hat dieses merkwürdige Verhalten damit etwas zu tun.
Bislang arbeite ich mit SQL-Statements zur Manipulation der Daten, vielleicht ist das das Problem. Ich werde mal ausprobieren, die Änderungen über die visuellen Komponenten durchzuführen.

Ciao,
Dirk

Hallo,

DirkOz hat folgendes geschrieben:

...Um den Wert also korrekt in Delphi zu bekommen, müsste ich die Backslashes doppelt maskieren, damit beim Zurücklesen der Backslash erhalten bliebe, also insert ... values ('\\\\\'e4') Damit bekomme ich aber wieder Probleme mit den Rave-Reports. Da muss es doch eine einfachere Lösung geben, oder? Ich kann vor lauter Backslashes schon kaum noch geradeaus schreiben

wie ist es denn wenn Du Backslash \ und Hochkomma ' wie z.B Umlaute maskierst

Hi!

So habe ich auch angefangen, bis ich nach 3 Stunden nicht mehr wusste, wo an welcher Stelle wie maskiert wird. Das war dann der Punkt, hier zu posten
Obwohl ich gerade den Weg über die DB-Komponenten ausprobiere, hier nochmal zur Veranschaulichung die Maskierungskette der Daten (zu lesen ohne die Anführungszeichen):

Im RTF-Feld steht für den User sichtbar:
"Ächz"
Im RTF-Quelltext steht:
"\'e4chz"
Damit für das INSERT-Statement Backslash und Hochkomma korrekt erkannt werden, wird der String wie folgt maskiert:
"\\\'e4chz"
Damit landet in der Datenbank:
"\'e4chz" (was ja soweit gut ist)
Das Auslesen des Textes per "fieldbyname('langtext').asstring" liefert aber:
"1/4hz" (1/4 steht da allerdings als einzlnes ACSII-Sonderzeichen)

=> beim Auslesen per ".asstring" wird der Stream von irgendeiner Instanz interpretiert, die Backslashes werden in Sonderzeichen umgewandelt. Das zu Umgehen ist das Problem, ich finde in den Zeos-Komponenten keine Schalter, die dieses Verhalten steuern. Die Lösung, doppelt zu maskieren, sa dass in der DB steht "\\\'e4chz', so dass das beim Auslesen wieder korrekt umgesetzt wird, funktioniert zwar, allerdings kann ich dann nicht mehr mit den Rave-Reports darauf zugreifen. Offensichtlich geschieht dort der Zugriff über einen anderen Weg.
Wenn ich nicht vorher verrückt werde, bleibe ich am Ball.

Ciao,
Dirk

Vielleicht hilft dir ja der Beitrag 'Postgres bytea Fields twice decoded' im ZEOS-Forum weiter. Er steht zwar in der Rubrik '6.5.1 (alpha)', aber vielleicht war dieser Fehler ja bereits in der 6.0.12 vorhanden...

[edit] Oder noch besser: gleich den ersten Beitrag 'PG8 Blob-Problem' in der gleichen Rubrik lesen...[/edit]

Grüße
Mikhal

Es ist soweit: ich gebe auf.
Ich habe eben das Beispiel zu Blobs, das in den Zeos-Libs enthalten ist, compiliert und vorher die DBMemo-Komponente durch eine TDBRichedit-Komponente ersetzt. Folgendes passiert:
- Programmstart
- Verbindungsaufbau, Tabellen werden geöffnet, 2 Datensätze existieren
- in den ersten schreibe ich (im RTF-Feld) "test", im zweiten "test2" (und speichere natürlich)
- beide werden beim hin- und herblättern korrekt angezeigt

Und jetzt kommt's:

Sobald ich die Verbindung trenne und wieder neu öffne, erscheint im RTF-Feld wieder der gefürchtete Kauderwelsch. Das bedeutet meiner Meinung nach, dass da ein genereller Fehler vorliegt (ich vermute, die Daten werden gecached, solange die Verbindung steht, darum sah es erst richtig aus). Vielleicht gehe ich dann doch lieber über die ODBC oder so, die Frage ist jedenfalls für mich damit abgeschlossen.

Danke den Mitwirkenden für die Tipps bis hierher.

Ciao,
Dirk

Schau dir doch mal die PostgresDAC von Microolap an. Vielleicht helfen dir dir weiter. Ich habe gute Erfahrungen mit ihnen gemacht, sie kosten nur halt ein paar Euro...

Grüße
Mikhal