Umlaute-Problem bei Leistungsdatenübersicht

[Dittich]

Hallo,

wir haben seit jeher das Problem, dass wenn wir die Leistungsdatenübersicht in der Oberstufe ausdrucken wollen, Schüler mit Umlauten im Namen nicht dargestellt, bzw. nicht gefunden werden und somit keine Auswertung stattfindet.
Dazu hat der bisherige Kollege dann immer die Umlaute geändert: ä --> ae (usw.)

Aber das kann ja wohl nicht der Normalfall sein. Daher meine Frage ans Forum, woran das evtl. liegen könnte.

Wir benutzen Schild mit einer Anbindung an eine MySQL-DB, welche auf einem Linux-Server läuft.

Bei den anderen Formularen taucht der Fehler übrigens nicht auf (z.B. Zeignisdruck). Dort werden die Umlaute sauber erkannt und genutzt.

Beste Grüße mit der Hoffnung auf Hilfe,
Carsten Dittich

[Pfotenhauer]

Hallo.

Welchen Leistungsübersicht-Report soll nutzen Sie denn?
Welchen Zeichensatz haben Sie in MySQL verwendet?

[Dittich]

Hallo,

es handelt sich dabei um den Bericht zu den Leistungsübersichzten Sek 2 -EF. (mit Versetzung und FOR)

Die DB läuft auf latin1_swedish_ci. Meine Vermutung ist, dass ich dort umstellen sollte auf utf8_general_ci.

Carsten Dittich

[M. Plümper]

Die Problematik habe ich seinerzeit mal untersucht. Das Problem liegt in der Sortierung der Einträge in den eigenen Datenquellen. Da das innerhalb der Reporting abläuft, habe ich darauf keinen Einfluss. Ein Test mit einem anderen Zeichensatz konnte ich noch nicht durchführen.

[Pfotenhauer]

Vielleicht haben Sie ja die Möglichkeit mal an einer Demo-Datenbank mal auf UTF8.... umzustellen.

[Dittich]

Habe die letzte Stunde nun damit verbracht, mit der Konsole in MySQL rumzuwerkeln und eine Kopie der DB auf UTF8 zu bringen (mit allen Tabellen).
Leider ohne Erfolg. Das Problem bleibt bestehen.

Nun vermute ich, dass das Formular, welches ja nicht direkt auf die DB-Felder zugreift, sondern sich eigene DB-Verknüpfungen zusammenbaut (meine ich zumindest) und über diese die Daten zieht, dort fehlerhaft ist. ABER, ich verspüre gerade nicht die geringste Lust, genau diese Strukturen nach einem Fehler zu durchsuchen. So tief habe ich den Formulardesigern und seine Verknüpfungen zur DB noch nicht verinnerlicht.

Carsten
(etwas demotiviert gerade)

-------------------

Immer noch demotiviert, aber ein wenig schlauer.
Wenn man im Report-Designer sich die Daten anschaut und sich die SQL-Anweisungen der einzelnen Tabellen genauer ansieht, sieht alles OK aus. Die Daten werden korrekt ausgelesen (Getestet mit phpMyAdmin und SQL-Abfrage). Der Unterschied zwischen der latin_swedish und der utf8_general liegt in der "Sortierung". Das bedeutet, die Schüler mit den Umlauten werden im latin_swedish ans Ende gehangen während bei utf8 die Namen einsortiert werden (intuitiv).

Stellt sich für mich als nächstes die Frage, warum die Daten dann unsauber, bzw. gar nicht aus der Datenbank gezogen werden, wenn das Formular erstellt wird. Wie gesagt, die SQL-Abfragen sind OK.

Achja, und immer noch demotiviert.

[M. Plümper]

Hallo Herr Dittich,

die eigenen Datenquellen (siehe Bereich Daten im Report-Designer) greifen direkt auf die Datenbank zu. Die normalen Datenquellen (Schueler usw.) sind Datenstrukturen, die über die Datenbank gelegt wurden.

Diese eigenen Quellen sind untereinander verknüpft. Und leider scheint es dabei innerhalb der Report-Komponente, also außerhalb des Einflussbereiches von Ihnen, mir und den SchILD-Entwicklern, ein Problem zu geben, weil die Sortierung der einzelnen Quellen unterschiedlich ist, sodass die Daten nicht korrekt einander zugeordnet werden.

Ihre Idee, die Sortierungen zu ändern, könnte helfen. Können Sie nicht ein Backup in eine neue DB erstellen ("Clonen") und deren Sortierung anpassen?