Tach!
Im PhpMyAdmin kann ich mir sowohl die Tabelle in DB1 als auch die View auf die Tabelle in DB2 mit korrekten Umlauten anzeigen lassen.
Wenn PhpMyAdmin alle Umlaute in allen Tabellen korrekt anzeigt, warum sollte dann Murks in den Feldern stehen?
Meine Schlussfolgerungen werden falsch, wenn die Gegebenheiten doch andere sind, als ich bisher kannte. Wenn der phpMyAdmin in beiden Fällen richtige Umlaute anzeigen kann, sind die Daten deines neuen Moduls wohl doch richtig kodiert im System gelandet. Das würde bedeuten, dass dieses die Verbindungskodierung richtig setzt. Oder eher unwahrscheinlich (weil unsinnig, wenn man mit UTF-8 im Frontend arbeitet), alles nach Latin1 umkodiert.
Dann müsstest du erst einmal mit einem Programm, das korrekt mit MySQL spricht (phpMyAdmin zum Beispiel) alle Nicht-ASCII-Zeichen (Umlaute etc.) korrigieren. Dann muss der neue Teil die Verbindungskodierung UTF-8 bei jedem Verbindungsaufbau aushandeln.
Ich verstehe leider nicht, inwiefern ich wo etwas inhaltlich korrigieren kann, da der Inhalt der Tabelle aus DB1 unangetastet bleiben muss und die View ja selbst keine Daten enthält.
Wenn alles gut vom PMA angezeigt wird, ist keine Korrektur notwendig. Dann sollte aber auch ohne irgendwelche händischen Umkodierungen alles korrekt ablaufen.
Aber ich werde versuchen, im neuen Modul die Verbindungskodierung immer mitzugeben.
Schau mal, ob es da wirklich fehlt.
Im alten Teil ist das leider sehr sehr umfangreich, da der Verbindungsaufbau an sehr vielen Stellen durchgeführt wird. (Ist leider so gewachsen und kaum noch korrigierbar)
Es gibt Editoren, die können in einem Verzeichnis nach Vorkommen von mysql_connect() suchen. Da ein mysql_set_charset(...) hinzuzufügen, ist so aufwendig nun auch wieder nicht.
dedlfix.