Problem mit Umlauten und Collations

[dedlfix]

Tach!

Damit müsste es möglich sein, beide Views mit derselben Codierung erstellen zu lassen.

Views haben keine Kodierungsangabe. Erst zur Laufzeit wird diese interessant, aber ob View oder direktes Statement, ist belanglos.

Ich denek aber, dass MySQL "Set Names" nicht mehr gerne sieht.

SET NAMES ist eine Erleichterung, um drei Konfigurationswerte gleichzeitig zu setzen. Dasselbe macht die MySQL-API-Funktion mysql_set_character_set() auch, nur dass sie zusätzlich im Client noch die verwendete Kodierung vermerkt, so dass mysql_real_escape_string() richtig arbeiten kann. Das ist aber für ASCII-basierende Kodierungen unerheblich, weil alle zu behandelnden Zeichen im ASCII-Teil liegen und es somit egal ist, weil das Ergebnis stets dasselbe ist und der Rest nicht beeinflusst wird.

Wenn die Client-API die Kodierung nicht kennt, ist das auch kein Beinbruch für die Daten, denn diese werden von ihr nicht verändert oder interpretiert, sondern nur durchgereicht. SET NAMES oder mysql_set_character_set() zu verwenden, nimmt sich praktisch also gar nichts. Demzufolge ist ein "nicht gerhe sehen" ohne Grundlage.

Kommt allerdings darauf an... Wenn Du Encoding und Collation gleichzeitig umschalten willst, was mMn ja sinnvoll ist, tut es ja seine Aufgabe.

Eine Kollationsangabe hängt immer hinter einer Kodierung. Die gibt es nicht einzeln. Man kann die Kodierung ohne Kollationsberücksichtigung umschalten, wenn man keine Stringvergleiche hat. Man kann aber nicht die Kollation nachträglich wechseln, das geht nur in Einheit mit der Kodierung.

Eine Kollationsangabe auf einer Verbindung ist nur dann interessant, wenn in den Statements Stringvergleiche vorkommen. Wenn Feldinhalte verglichen werden, mit literalen Strings im Staement oder mit anderen Feldern, dann ist die Feld-Kollationsangabe entscheidend und die Kollation der Verbindung bedeutungslos. Das heißt, dass man die Verbindungskollation üblicherweise unbeachtet lassen kann, denn Vergleiche zwischen literalen Strings im Statement sind eigentlich sinnlos und könnten gleich durch ihr Ergebnis ersetzt werden.

Ein Punkt ist vielleicht noch kritisch (?)
Wenn die View statische Referenzen enthält, wird es wahrscheinlich relevant sein, mit welcher Codierung die nun wieder erfasst worden sind.

Nö, du hast ja eine Kodierung auf der Verbindung ausgehandelt. Gemäß dieser werden die Statements interpretiert. Der Rest ist dann MySQLs Sache.

dedlfix.