MySQL Workbench

[Bernhard Geyer]

Zitat:

Zitat von Delbor (Beitrag 1176516)

Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe - mit meinem Programm eingefügte Strings kommen nach wie vor als 'verunstaltete' Zeichhenfolgen daher.

Welche Zeichensatzeinstellung? Für das DBMS? Für die DB? Für die einzelne Tabelle? Für deine Connection?

[mkinzler]

Zitat:

Es ist möglich, dass die entsprechende Passage in dem Buch für den PrimaryKey den AutoInc voraussetzte

Ohne autoinc muss das Feld auf jeden Fall gesetzt werden. Für einen ( künstlichen) PK ist autoinc eine gute Option.

Zitat:

Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe

Oder der Zugriffskomponente

[Delbor]

Hi zusammen

Zitat:

Zitat von mkinzler (Beitrag 1176524)

Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe

Oder der Zugriffskomponente[/QUOTE]

Der Zugriffskomponente? Da gibt's bei mir gerade mal die TSQL-Connection, TSQLDataset und TDatasource als Verbindung zu einem DB-Grid.
In einem Beispiel zu DBExpress emppfiehlt Embarcadero zwar eine 'Schlange' aus den Komponenten TSQLConnection,TSQLDataset, (TDatasource*), TClientDataSet und TDataSetProvider, die ich aber nicht verwende - ich habs mal versucht, aber irgendwie nicht die richtige Reihenfolge beim setzen der Propertys/nicht die richtige Komponente zum setzen eines/der Propertys erwwischt.
Seither begnüge ich mich mit den zuerst genannten 3 Komponenten. Und die bieten keine speziellen Propertys zum setzen des Zeichensatzes an, soweit ich gesehen habe.
Nach diesen Erklärungen ist dies aber auch gar nicht nötig - es ist letzlich so oder so eine Frage der Variablendeklaration..
Widerspruch wird gerne entgegengenommen.

Zitat:

Welche Zeichensatzeinstellung? Für das DBMS? Für die DB? Für die einzelne Tabelle? Für deine Connection?

Hmm, sehr gute Frage. Beim Erstellen des DB-Modells in MySQL-Workbench stelle ich die Sortierfolge (Collation) der Tabellen immer auf latin1-swedish_ci ein - damit ist der Zeichensatz automatisch latin1. Soweit ich die Hilfen richtig interpretiert habe (die sind in Workbench alle englisch), ist der Zeichensatz des MySQL-Servers standardmässig utf8 - und latin1 soll damit kompatibel sein. Der (Default-)Zeichensatz der DB selbst sollte eigentlich auch latin1 sein. Sollte er undefiniert sein, gilt für die DB m.W. die Einstellung des Servers. Entscheidend ist aber letztlich die Einstellung der Tabelle, respektive der Spalten (nicht-Var-Spalten können in Workbench gar keine Collations zugewiesen werden).
Den Zeichensatz der Connection (nicht Delphis TConnection-Komponente) sollte auch latin1 sein, aber das müsste ich nochmal überprüfen.


(*) Die wird m.W. da auch nur benötigt, wenn die SQL-Abfrage kein eigenes Grid zur Datenausgabe erzeugt.

Gruss
Delbor

[Bernhard Geyer]

Zitat:

Zitat von Delbor (Beitrag 1176531)

Den Zeichensatz der Connection (nicht Delphis TConnection-Komponente) sollte auch latin1 sein, aber das müsste ich nochmal überprüfen.

Das ist die Frage und hier ist die Frage ob die Delphi-Komponente das richtig macht.

Wenn die verwendete Komponente z.B. nur die DB-Einstellung prüft und Latin1 sieht und dann auf einer utf8-Verbindung uncodiert Sonderzeichen abschickt wird der Server diese Zeichen natürlich als Falsch codiert ansehen und entsprechend Markieren.

[Delbor]

Hi Bernhard

Hier mal ein Jpeg mit den Einstellungen der entsprechenden Systemvariablen.

Da ist alles utf8.

Im Konfigurationsfenster des Servers lässt sich allerdings die Collation einstellen. Ich habe das mal auf latin1-swedish_ci geändert. Da bislang keine Änderung erfolgt ist, nehme ich an, dass ein Neustart des Servers erforderlich ist.

Wenn ich die verlinkte Hilfeseite alledings richtig interpretiert habe, sollte der normale (Unicode-)String von DelphiXE mit utf8 klarkommen, bzw. umgekehrt...

Gruss
Delbor

[Bernhard Geyer]

Zitat:

Zitat von Delbor (Beitrag 1176538)

Im Konfigurationsfenster des Servers lässt sich allerdings die Collation einstellen. Ich habe das mal auf latin1-swedish_ci geändert. Da bislang keine Änderung erfolgt ist, nehme ich an, dass ein Neustart des Servers erforderlich ist.

Deine Datenbank(tabellen) die schon erstellt wurden bleiben trotzdem auf UTF8. Das was du als Systemeinstellung einstellst ist sowas wie Vorgabe (Tabell erstellen ohne Collation-Angabe -> Nimm Systemvorgabe). Collations von Existierenden Elementen werden nicht geändert.

Zitat:

Zitat von Delbor (Beitrag 1176538)

Wenn ich die verlinkte Hilfeseite alledings richtig interpretiert habe, sollte der normale (Unicode-)String von DelphiXE mit utf8 klarkommen, bzw. umgekehrt...

Nicht unbedingt. Über TCP/IP kann MySQL nur 1-Byte Charactersets. Die Zugriffskomponente muss entsprechend UTF8/Unicode-Zeichen korrekt umcodieren. Evtl. ist ein Bug in den Kompos von Delphi

[Delbor]

Hi Bernhard

Zitat:

Wenn die verwendete Komponente z.B. nur die DB-Einstellung prüft und Latin1 sieht...

Ich denke, ich habe alle verwendeten Komponenten nach einem Property zur Einstellung des Zeichensatzes durchsucht, auch diejenigen der erwähnten 'Schlange' aus dem DBExpress-Beispiel, bin aber bislang nicht fündig geworden. Deshalb gehe ich ja davon aus, dass zum korrekten schreiben und lesen des Strings allein die verwendeten Variablentypen (AnsiString, Widestring etc. verantwortlich sind.

Gruss
Delbor

[Delbor]

Hi Bernhard

Zitat:

Nicht unbedingt. Über TCP/IP kann MySQL nur 1-Byte Charactersets. Die Zugriffskomponente muss entsprechend UTF8/Unicode-Zeichen korrekt umcodieren. Evtl. ist ein Bug in den Kompos von Delphi

Wie geht dann MYSQL mit Zeichensätzen um, die mehr als 1 Byte haben/haben können?
Datebank-Server innerhalb Japans zB sind wohl kaum mit 1-Byte-Zeichensätzen konfiguriert.
Und ausser TCP/IP ist TCP/IP über SSH oder als 3. Möglichkeit über local Socket/Pipe möglich - und eigentlich sollte MySQL nur gerade über letztere Verbindung Zeichensätze mit mehr als einem Byte verarbeiten können - und würde dadurch wohhl für die Verwendung über Internet ausfallen...
Also muss ich wohl irgendwas völlig falsch verstanden haben...

Gruss
Delbor

[Delbor]

Hi zusammen

Dachte ich mir's doch:

Zitat:

Da ISO-8859-1 nur ein Byte zur Kodierung eines Zeichens verwendet,

Das soll Missverständnisse verhindern, die dadurch entstehen könnten:

Zitat:

Über TCP/IP kann MySQL nur 1-Byte Charactersets.

In älteren MySQL-Versionen ist dies zwar noch denkbar, aber nicht ab MySQL 5.5 (?).

Im Programm lassen sich die Zeichensätze für die aktuelle Session ändern - meine komischen Ausgaben wie zB "Ã#ste" statt Äste sind dann für die Laufzeit des Programms kein Problem mehr. (Wobei das Sharp für ein mir unbekanntes, leicht ähnliches Zeichen steht).
Die Syntax: 'SET NAMES ´latin1`. Damit ist der Zeichensatz allerdings nur gerade zur aktuellen Programmlaufzeit gültig - der Zeichensatz des Servers ist weiterhin utf8 (Standard ab 5.?).

Zur Beruhigung all jener, für die das Thema auch etwas rätselhaft ist...


Gruss
Delbor

[mquadrat]

Also zunächst mal muss man ja zwischen Character-Set und Collation unterscheiden. Sind ja unterschiedliche Sachen. Die sollten allerdings zusammenpassen. Eine Tabelle mit Character-Set UTF8 und Collation latin1_* macht keinen Sinn. Zweite Aussage: Daten die falsch gespeichert wurden, bleiben auch nach dem Umstellen falsch.

- Character-Set der Tabelle prüfen
- Collation der Tabelle prüfen
- Beim Aufbauen der Verbindung Sets via SET NAMES und SET CHARACTER SET für die Verbindung einstellen

Wird alles explizit gesetzt, ist die Einstellung des Servers übrigens egal.

Manche Komponenten haben eine Property für den Character-Set der Verbindung und führen die SET Befehle beim Verbindungsaufbau dann automatisch aus. Normalerweise sollte die Komponente die u.U. nötige Umwandlung von Unicode nach Latin1 und/oder zurück selber hinkriegen.