MySQL: Zeichensatz unter Windows, DB-Verzeichnisse

[idefix2]

Hallo,

ich habe mir eben einen MySQL Server installiert, weil ich daran denke, meine Applikationen von MS-Access auf MySQL umstellen. Aber noch bevor ich zu den allerersten Schritten komme, tun sich schon die ersten zwei Hindernisse auf:

Ich habe MySql mit den Standardvorgaben installiert - da heisst der Zeichensatz Latin-1 - bei dem werden aber alle Umlaute aus den Access-Tabellen zu irgendwas unbrauchbaren konvertiert. Welcher MySQL Zeichensatz entspricht dem normalen in Windows verwendeten Zeichensatz?

und die zweite Frage: Ich würde gerne verschiedene Datenbanken an verschiedenen Orten des Servers, teilweise auch auf unterschiedlichen Platten, anlegen, und zwar jeweils in ein Unterverzeichnis der zugehörigen Applikation. Ist das mit MySQL überhaupt möglich?

[Bernhard Geyer]

Zitat von idefix2:

Ich habe MySql mit den Standardvorgaben installiert - da heisst der Zeichensatz Latin-1 - bei dem werden aber alle Umlaute aus den Access-Tabellen zu irgendwas unbrauchbaren konvertiert. Welcher MySQL Zeichensatz entspricht dem normalen in Windows verwendeten Zeichensatz?

Nimm UTF8/UCS2 bei MySQL und alles wird gut. In 2010 mit Codepages/Charsets sich herumärgern ist für ein neues Projekt ein absolutes NO-GO.

[idefix2]

Leider wurde nicht alles gut:

Ich habe den default charset von MySQL auf UTF8 umgestellt, den MySQL-Dienst neu gestartet (steht jetzt auch in DB.OPT so drinnen) und eine neue Datenbank und darin eine neue Tabelle erstellt.

Ich habe aus meiner alten Access-Datenbank ein Tab-delimited file erzeugt, in diesem File zeigt mir z.B. der Windows Editor die Umlaute richtig an, habe dann noch alle "\" in "\\" konvertiert und dann:

LOAD DATA LOCAL INFILE 'd:/test.txt' INTO TABLE musik;

auf der MYSQL Kommandozeile eingegeben, um die Tabelle zu importieren.

Ergebnis: Die Tabelle wird zwar importiert, aber alle Felder, die Umlaute enthalten, brechen jetzt unmittelbar vor dem ersten Umlaut ab, enthalten also nur die Zeichen bis zum ersten Umlaut - mit latin1 wurden zwar die Umlaute falsch konvertiert, aber zumindest die Datenfelder komplett eingelesen.

[mkinzler]

Ich würde die Daten direkt von der Access-Tabelle in die MySQL-Tabelle kopieren.

[mjustin]

Zitat von idefix2:

Leider wurde nicht alles gut:

Ich habe den default charset von MySQL auf UTF8 umgestellt, den MySQL-Dienst neu gestartet (steht jetzt auch in DB.OPT so drinnen) und eine neue Datenbank und darin eine neue Tabelle erstellt.

Ich habe aus meiner alten Access-Datenbank ein Tab-delimited file erzeugt, in diesem File zeigt mir z.B. der Windows Editor die Umlaute richtig an, habe dann noch alle "\" in "\\" konvertiert und dann:

LOAD DATA LOCAL INFILE 'd:/test.txt' INTO TABLE musik;

auf der MYSQL Kommandozeile eingegeben, um die Tabelle zu importieren.

Ergebnis: Die Tabelle wird zwar importiert, aber alle Felder, die Umlaute enthalten, brechen jetzt unmittelbar vor dem ersten Umlaut ab, enthalten also nur die Zeichen bis zum ersten Umlaut - mit latin1 wurden zwar die Umlaute falsch konvertiert, aber zumindest die Datenfelder komplett eingelesen.

Eventuell ist diese Seite hilfreich:

"LOAD DATA INFILE and UTF-8"
http://bugs.mysql.com/bug.php?id=10195

Dort werden diverse Parameter und Umgebungsvariablen beschrieben.

Was ich (ohne die genannte Seite gelesen zu haben) intuitiv versuchen würde wäre, die Textdatei in UTF-8 zu kodieren, z.B. in der Delphi IDE.

[idefix2]

Danke, die Seite war hilfreich: Ich werde von MySQL die Finger lassen.

Bei einem DBMS, das auf einem PC laufen soll, und das im Jahr 2010 offenbar noch nicht die Möglichkeit bietet, normale PC-Umlaute auf einfache Art zu handhaben, fühle ich mich nicht gut aufgehoben

[Bernhard Geyer]

Zitat von idefix2:

Danke, die Seite war hilfreich: Ich werde von MySQL die Finger lassen.

Bei einem DBMS, das auf einem PC laufen soll, und das im Jahr 2010 offenbar noch nicht die Möglichkeit bietet, normale PC-Umlaute auf einfache Art zu handhaben, fühle ich mich nicht gut aufgehoben

Also wir verwenden MySQL mit Unicode (Deutsche Umlaute, Chinesisch, Ararbisch) seit ca. 2003 und haben damit eigentlich sehr wenig Probleme (im Gegensatz zu diversen Oracle-Installationen). Im Notfall implementiert man sich eine eigene "Datapump" in 1-2 Tagen.

[mkinzler]

Aus meiner Sicht würden eher andere Dinge gegen MySQL sprechen

[Bernhard Geyer]

Zitat von mkinzler:

Aus meiner Sicht würden eher andere Dinge gegen MySQL sprechen

Wenn man die Punkte betrachtet:

Zitat von idefix2:

und die zweite Frage: Ich würde gerne verschiedene Datenbanken an verschiedenen Orten des Servers, teilweise auch auf unterschiedlichen Platten, anlegen, und zwar jeweils in ein Unterverzeichnis der zugehörigen Applikation. Ist das mit MySQL überhaupt möglich?

Würde das eher nach einer embedded-DB-Lösung sprechen. Hier wäre MySQL auch im Rennen, wenn da nicht die GPL-Falle zuschlägt:

Frage:
Sind die Anwendungen OpenSource-Anwendungen?
Falls nein: Können 30 k€ pro Jahr Lizenzkosten verkraftet werden (bzw. 1 MySQL-Serverlizenz pro Server?)

[mkinzler]

Muss nicht unbedingt für embedded sprechen. Jede Anwendung könnte ja theoretisch von mehreren Benutzern verwendet werden.
Wenn es sich um keine OS Lösung handelt und die Anwendungen u.U. weitergegeben werden sollen, würde ich nicht aud MySQL setzen.
Zudem hier weitere Änderungen seitens Oracle zu befürchten sind ( droppen der Falcon-Storage-Enhine vom Interbase/Firebird "Erfinder" Jim Starkey ist möglichweise nur der 1. Schritt)