Welcher Zeichensatz für neue DB (über Zeos) empfehlenswert?

**MatthiasR**

Da wir momentan was PostgreSQL angeht noch recht grün hinter den Ohren sind, uns aber entschieden haben, es für kommende Projekte einzusetzen, stellt sich für mich gerade die Frage nach dem "richtigen" Zeichensatz für neue Datenbanken. Zugegriffen werden soll darauf mittels den Zeos-Komponenten (momentan) aus Delphi 7.

Standardmäßig ist bei PostgreSQL ja UTF8 als Zeichensatz für neue Datenbanken eingestellt (in diesem pgAdmin-Tool). Da UTF8 sowohl unter einem Windows- als auch Linux-Server zu Verfügung steht, wäre das erstmal die erste Wahl. Problem an der Geschichte ist nur die Client-Seite: Umlaute werden im Delphi-DBGrid falsch angezeigt. Auch wenn ich per INSERT-Befehl einen AnsiString, der Umlaute enthält, in eine UTF8-Datenbank einfügen will, kommt eine Fehlermeldung:

Zitat:

SQL Fehler: ERROR: invalid byte sequence for encoding "UTF8": 0xfc
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".

Eine Möglichkeit, den Fehler zu umgehen, wäre da vorherige Wandeln des AnsiString in UTF8 mittels AnsiToUTF8. Allerdings ist das recht mühsam, da jedes mal dran zu denken, außerdem löst das nach wie vor das Problem der Anzeige im DBGrid nicht.

Was also tun?

1. Gibt es irgend eine Möglichkeit, das DBGrid (oder DataSource oder Query oder Connection) irgendwie auf UTF8 umzustellen?

2. Ist UTF8 als Zeichensatz überhaupt empfehlenswert? Ich habe bei meinen bisherigen Tests auch den WIN1252-zeichensatz verwendet, weil ich damit die Probleme nicht habe. Allerdings steht der mir unter Linux nicht zu Verfügung, und wir haben auch Linux DB-Server im Einsatz.

Vielen Dank für eure Hilfe

!

**MatthiasR**

OK, löse hier mal selbst auf: das Zauberwort heißt Client-Encoding. Ich übermittle dem Postgres-Server nun nach dem verbinden, dass ich als Client-Encoding LATIN9 (= ISO-8859-15) verwenden will, und prompt passen die Umlaute im DBGrid wieder

. Und auch bei INSERT-Befehlen beschwert er sich nun nicht mehr über fehlerhafte UTF-8-zeichen, weil er die Daten fortan auch in LATIN9 erwartet.

markieren

Delphi-Quellcode:

			procedure TForm1.ZConnection1AfterConnect(Sender: TObject);

begin

  ZConnection1.ExecuteDirect('SET CLIENT_ENCODING TO ''LATIN9'';');

end;

Für mich ein gangbarer Weg

**Bernhard Geyer**

Kommt ZEOS nicht mit UTF8 zurecht so das es eine Transparente Codierung UTF8 <-> Unicode vornimmt

Für größere Apps würde ich eh die DB-Schnittstelle z.B. mit Bridge-Pattern kapseln und wenn möglich auf DB-Sensitive Controls verzichten. Damit kannst du die nötigen Wandlungsfunktionsaufrufe in einer Klasse/Unit kapseln/zentrieren.

**MatthiasR**

Zitat von Bernhard Geyer:

Kommt ZEOS nicht mit UTF8 zurecht so das es eine Transparente Codierung UTF8 <-> Unicode vornimmt

Ich weiß nicht, ob ich dich richtig verstanden habe, aber ein "INSERT INTO tabelle VALUES ('türöffner');" mittels TZQuery auf eine UTF8-Datenbank endet in einem Fehler. Und das DBGrid in Delphi 7 ist ja noch nicht Unicode-fähig, falls du das gemeint hast.

Zitat von Bernhard Geyer:

Für größere Apps würde ich eh die DB-Schnittstelle z.B. mit Bridge-Pattern kapseln und wenn möglich auf DB-Sensitive Controls verzichten. Damit kannst du die nötigen Wandlungsfunktionsaufrufe in einer Klasse/Unit kapseln/zentrieren.

Was spricht gegen datensensitive Controls wie ein DBGrid? Das Ergebnis einer komplexeren SQL-Abfrage möchte ich jedenfalls nicht von Hand in ein Grid eintragen müssen...
Eine gewisse Zentralisierung des Datenzugriffs ließe sich ja mittels Connection auf Datenmodul erreichen. Was spricht dagegen, bei den verschiedenen Formularen mit DB-Zugriff auf die TZQuery zurückzugreifen?

**Bernhard Geyer**

Zitat von Infect:

Ich weiß nicht, ob ich dich richtig verstanden habe, aber ein "INSERT INTO tabelle VALUES ('türöffner');" mittels TZQuery auf eine UTF8-Datenbank endet in einem Fehler.

Man sollte eh immer parametrisierte Abfragen machen. Dann vermeitet man Problem die bei direkter angabe der Werte entstehen.

Zitat von Infect:

Und das DBGrid in Delphi 7 ist ja noch nicht Unicode-fähig, falls du das gemeint hast.

Um ein üöä zu bekommen braucht man keine Unicodefähiges Grid.

Zitat von Bernhard Geyer:

Was spricht gegen datensensitive Controls wie ein DBGrid? Das Ergebnis einer komplexeren SQL-Abfrage möchte ich jedenfalls nicht von Hand in ein Grid eintragen müssen...

Zig mal gemacht - Äh einmal gemacht. Ist für eine einfache lösung vieleicht 20 Zeilen lang.

Zitat von Bernhard Geyer:

Eine gewisse Zentralisierung des Datenzugriffs ließe sich ja mittels Connection auf Datenmodul erreichen. Was spricht dagegen, bei den verschiedenen Formularen mit DB-Zugriff auf die TZQuery zurückzugreifen?

Vermeidung nur ein DBMS zu unterstützen zu können (falls deine App verkauft werden soll). Wenn man 2-3 Anbietet kann der Kunde seine eh schon im Haus befindliche DB verwenden. Bei einer bist immer DU als SW-Entwickler für alles Verantwortlich (bzw. es wird versucht dich dafür verantwortlich zu machen): "Sie haben doch mal die DB auf unseren Server installiert. Jetzt geht das auf einmal das nicht und wir denken ihre DB ist schuld".

**MatthiasR**

Zitat von Bernhard Geyer:

Zitat von Infect:

Ich weiß nicht, ob ich dich richtig verstanden habe, aber ein "INSERT INTO tabelle VALUES ('türöffner');" mittels TZQuery auf eine UTF8-Datenbank endet in einem Fehler.

Man sollte eh immer parametrisierte Abfragen machen. Dann vermeitet man Problem die bei direkter angabe der Werte entstehen.

Sollte doch nur ein Beispiel sein, ich arbeite mit Parametern.

Zitat von Bernhard Geyer:

Zitat von Infect:

Und das DBGrid in Delphi 7 ist ja noch nicht Unicode-fähig, falls du das gemeint hast.

Um ein üöä zu bekommen braucht man keine Unicodefähiges Grid.

Auch das ist mir klar. Ich wollte wissen was du mit "Transparente Codierung UTF8 <-> Unicode" gemeint hast.

Zitat von Bernhard Geyer:

Zitat von Infect:

Was spricht gegen datensensitive Controls wie ein DBGrid? Das Ergebnis einer komplexeren SQL-Abfrage möchte ich jedenfalls nicht von Hand in ein Grid eintragen müssen...

Zig mal gemacht - Äh einmal gemacht. Ist für eine einfache lösung vieleicht 20 Zeilen lang.

Mit datensensitiven Controls eben 0 mal gemacht. Was ist also besser?

Zitat von Bernhard Geyer:

Zitat von Infect:

Eine gewisse Zentralisierung des Datenzugriffs ließe sich ja mittels Connection auf Datenmodul erreichen. Was spricht dagegen, bei den verschiedenen Formularen mit DB-Zugriff auf die TZQuery zurückzugreifen?

Vermeidung nur ein DBMS zu unterstützen zu können (falls deine App verkauft werden soll). Wenn man 2-3 Anbietet kann der Kunde seine eh schon im Haus befindliche DB verwenden. Bei einer bist immer DU als SW-Entwickler für alles Verantwortlich (bzw. es wird versucht dich dafür verantwortlich zu machen): "Sie haben doch mal die DB auf unseren Server installiert. Jetzt geht das auf einmal das nicht und wir denken ihre DB ist schuld".

Die Zeos-Connection unterstützt ca. 8 verschiedene Datenbanken, außerdem noch ADO. Ich sehe nicht, wieso ich mich damit auf einen Anbieter, in diesem Fall Postgres, kastrieren würde?!?

**Alfredo**

Zu Eurer Datenbankwahl einige Hinweise:

Ich war auch überzeugt, dass Progress "die" Datenbank ist.

Die Praxis hat mich jedoch eines besseren belehrt.

1) Ihr solltet euch mit dem Thema Datensicherung auseinandersetzen
- Ihr werdet feststellen, dass diese bei Progress mit einem hohen
Aufwand verbunden ist.

2) Auf welchem Betriebssystem läuft in Zukunft der Postgress-Server?

a) Ich habe es unter Fedora aufgegeben mit Postgress zu arbeiten
- beim Update müssen alter und neuer Sever parallel laufen

b) Postgress wird derzeit intensiv gepflegt, was ja zunächst sehr
positiv ist, aber es wird dadurch ein regelmäßiger Updateauf-
wand verursacht
- wenn dann auch noch das Betriebssystem laufend hochgezogen
wird, dann geht das einem selbst und auch dem Kunden ganz
schön auf die Nerven
- es genügt eine einzige Fehlentscheidung und man hat richtig
Stress(z.B. hochziehen des Betriebssystem, ohne vorher einen
Dump der DB gezogen zu haben)

3) Einfach die DB zu wechseln ist Theorie.
- Postgress hat eine andere Schreibsyntax wie Firebird.

4) Zeos ist nicht frei von Problemen
- lies einfach mal im ZEOS-Forum mit

5) Heute ein neues Projekt mit D7 aufzusetzen ist auch nicht unproblematisch
- siehe die UTF8-Geschichte

Gruß
Alfred

**Bernhard Geyer**

Zitat von Infect:

Auch das ist mir klar. Ich wollte wissen was du mit "Transparente Codierung UTF8 <-> Unicode" gemeint hast.

Transparent heißt das du außerhalb der Zugriffskomponenten nicht bemerkst ob die DB UTF8 ist oder nicht (Außer das ohne UTF8 z.B. Kyrilisch und Arabisch nicht gemeinsam geht)

Zitat von Infect:

Die Zeos-Connection unterstützt ca. 8 verschiedene Datenbanken, außerdem noch ADO. Ich sehe nicht, wieso ich mich damit auf einen Anbieter, in diesem Fall Postgres, kastrieren würde?!?

Es unterstützt es, aber wenn du den Aufbau von SQL-Anweisungen zu stark im Quellcode streust hast du hohen aufwand auf andere SQL-Syntax zu wechseln.

**MatthiasR**

Zitat von Alfredo:

1) Ihr solltet euch mit dem Thema Datensicherung auseinandersetzen
- Ihr werdet feststellen, dass diese bei Progress mit einem hohen
Aufwand verbunden ist.

Was ist an pg_dump mit hohem Aufwand verbunden, wenn man erstmal die passenden Parameter für sich gefunden hat?

Zitat von Alfredo:

2) Auf welchem Betriebssystem läuft in Zukunft der Postgress-Server?

a) Ich habe es unter Fedora aufgegeben mit Postgress zu arbeiten
- beim Update müssen alter und neuer Sever parallel laufen

b) Postgress wird derzeit intensiv gepflegt, was ja zunächst sehr
positiv ist, aber es wird dadurch ein regelmäßiger Updateauf-
wand verursacht
- wenn dann auch noch das Betriebssystem laufend hochgezogen
wird, dann geht das einem selbst und auch dem Kunden ganz
schön auf die Nerven
- es genügt eine einzige Fehlentscheidung und man hat richtig
Stress(z.B. hochziehen des Betriebssystem, ohne vorher einen
Dump der DB gezogen zu haben)

Sowohl unter Windows, als auch Linux. Da es bei unseren Kunden nicht darauf ankommt, dass ihre Anlage rund um die Uhr läuft, haben wir bei Updates sicher nicht so den Stress, dass wir zwei Datenbank-Server parallel betreiben müssen. Außerdem werden wir sicherlich nicht jedes Mini-Update umgehend einspielen, sondern eher nur Major-Versions, sofern sie sinnvolle Verbesserungen bieten, von denen wir auch profitieren.

Zitat von Alfredo:

3) Einfach die DB zu wechseln ist Theorie.
- Postgress hat eine andere Schreibsyntax wie Firebird.

Was jetzt aber nicht wirklich ein Punkt gegen Postgres ist, sondern genauso gut einer gegen Firebird, bzw. eigentlich gegen so gut wie jedes DBMS, oder? Mir ist schon klar, dass ein DB-Wechsel nicht von heute auf morgen zu machen ist, aber von Postgres auf Firebird zu wechseln ist genauso schwierig, wie von Firebird auf mySQL oder was auch immer, möchte ich mal behaupten. Oder ist Postgres soooo viel spezieller als die anderen genannten Systeme?

Zitat von Alfredo:

4) Zeos ist nicht frei von Problemen
- lies einfach mal im ZEOS-Forum mit

Welche Software ist das schon? Zeos ist zumindest open-source, was bei mir persönlich ein besseres Gefühl hinterlässt, als auf eine closed-source Variante zu setzen. Nicht zuletzt auch ein weiterer Grund für Postgres.

Zitat von Alfredo:

5) Heute ein neues Projekt mit D7 aufzusetzen ist auch nicht unproblematisch
- siehe die UTF8-Geschichte

Soll ich nun deswegen den Compiler wechseln? Letztendlich lag es ja nur an einem nicht gesetzten Client-Encoding. Und genau dafür ist die Option ja da, damit man sie auch verwendet. Eine Codezeile hat das Problem bereits gelöst, also ist es ja im Nachhinein eigentlich nicht mal wirklich ein Problem gewesen.

Zitat von Bernhard Geyer:

Zitat von Infect:

Auch das ist mir klar. Ich wollte wissen was du mit "Transparente Codierung UTF8 <-> Unicode" gemeint hast.

Transparent heißt das du außerhalb der Zugriffskomponenten nicht bemerkst ob die DB UTF8 ist oder nicht (Außer das ohne UTF8 z.B. Kyrilisch und Arabisch nicht gemeinsam geht)

Durch das Setzen des Client-Encodings auf LATIN9 als Options-property innerhalb der Zeos-Connection, bemerke ich doch ausserhalb der Zugriffs-Komponente überhaupt nicht, welcher Zeichensatz von der Datenbank physikalisch nun verwendet wird. Man legt den Client-Zeichensatz an EINER Stelle in der Client-Anwendung fest (da nur eine Connection verwendet wird) und der Fisch ist geputzt?!?

Zitat von Bernhard Geyer:

Zitat von Infect:

Die Zeos-Connection unterstützt ca. 8 verschiedene Datenbanken, außerdem noch ADO. Ich sehe nicht, wieso ich mich damit auf einen Anbieter, in diesem Fall Postgres, kastrieren würde?!?

Es unterstützt es, aber wenn du den Aufbau von SQL-Anweisungen zu stark im Quellcode streust hast du hohen aufwand auf andere SQL-Syntax zu wechseln.

OK, das leuchtet mir ein. Du würdest also eine Schnittstellen-Unit vorschlagen, die z.B. Funktionen beinhaltet a la
function Select(const Select, From, Where: string): ResultSet; Also dass die richtige und für das DBMS passende SQL-Syntax intern nur an einer Stelle zusammengestellt wird? Bei simplen SQL-Statements der Form "SELECT spalte FROM table WHERE column = value;" mag das ja noch gut machbar sein, aber wenn die Statements mal richtig komplex werden? Man kann ja nicht für jede Eventualität eine Schnittstellen-Funktion schreiben? Was würdest du da vorschlagen? Wie gesagt, den Sinn davon sehe ich ein.