Umlautmurks II: SQLite als Übeltäterin bzw. ?*belt?*terin
Verfasst: 02.10.2008 10:51
Hallo Leute, ich hoffe, es ist bald das letzte Mal, dass ich euch mit Fragen bombardiere, aber wie gesagt, no good handbook, no real help...
Also zur Sache: Ich habe mittlerweile das Problem identifiziert, dass ich vor kurzem noch dem Listviewgadget anlastete: SQLite stellt keine "german Umlauts" dar. Ich habe mithin keinen Fehler bei der Konvertierung gemacht, sondern SQLite stellt die Umlaute und das "ß" allesamt als "?" dar. Meine in Rede stehende Datenbank ist auch schon auf UTF-8 eingestellt. Auch der Vorschlag von TS-Soft, den Befehl "SText = PeekS(@SText, -1, #PB_UTF8)" zu verwenden, um die Variable SText zu "konvertieren", nachdem sie den Inhalt des jeweiligen Datensatzes zugewiesen bekommen hat, hilft leider nicht weiter, da die Datenbank ja bereits das richtige Format hat. Auch die Umstellung des Compilerflags nutzt in diesem Fall nichts. Auch meine Idee, den Umlautmurks in der CSV per "Strg + F" zu ersetzen, ist hinfällig, da die Umlaute in der CSV-Datei noch korrekt gespeichert sind.
Meine Ansätze zur Lösung des Problems waren bzw. sind folgende:
1. Ich schreibe eine Prozedur, die mittles "FindString" und "ReplaceString" den von SQLite verursachten Umlautmurks bei Einlesen der Datensätze "zurückkonvertiert"; Problem: SQLite speichert jeden Umlaut unter dem selben Ersatzzeichen "? + noch irgendson Mistakronym" ab, eine Rückkonvertierung ist mithin - mangels eindeutiger Zurordnung - nicht möglich.
2. Ich schreibe eine Prozedur, die diese Konvertierung in der CSV-Datei vornimmt und "äöüß " in für SQLite lesbare Zeichen umwandelt und anschließend muss ich im Programm selbst - spiegelbildlich - dazu, eine Rückkonvertierungsprozedur schreiben. Mittlerweile bin ich soweit, dass ich das hinkriegen werde, da ich String-Konvertierungen bei VB hundertmal gemacht hab und diese sich bei PB so gut wie gar nicht von denen in VB unterscheiden.
Ich habe aber ehrlich gesagt, keine Lust, einen solchen Aufwand zu betreiben, der zudem noch die Fehleranfälligkeit des Progs erhöht, da mit jeder Umwandlungsroutine auch eine Fehlerquelle mehr entsteht.
Fällt euch, der ihr mir oftmals geniale Tipps gegeben habt und geholfen habt vor lauter Wald auch mal wieder die Bäume zu sehen, eine bequemere Lösung ein?
Wenn nicht, dann reicht's mir langsam mit dem Aufwand, den ich zur Konvertierung meiner Datenbank von Access in SQLite betreiben muss, ich werd das Thema dann endgültig abhaken und erst, wenn ein "vollautomatisches" Konvertierungsprogramm zur Verfügung steht, mal wieder an SQLite denken. Ich wollte ja auch erst mit meiner Probedatenbank (§ Tabellen) und dem Umlautmurks weitermachen, aber mittlerweile bin ich mit dem Rohgerüst meines User-Interfaces, nicht zuletzt dank eurer Hilfe, fast fertig und ich kann diese verfluchten ? + Hieroglyphen einfach nicht mehr lesen, da werd ich wahnsinnig.
Danke im Voraus!
Also zur Sache: Ich habe mittlerweile das Problem identifiziert, dass ich vor kurzem noch dem Listviewgadget anlastete: SQLite stellt keine "german Umlauts" dar. Ich habe mithin keinen Fehler bei der Konvertierung gemacht, sondern SQLite stellt die Umlaute und das "ß" allesamt als "?" dar. Meine in Rede stehende Datenbank ist auch schon auf UTF-8 eingestellt. Auch der Vorschlag von TS-Soft, den Befehl "SText = PeekS(@SText, -1, #PB_UTF8)" zu verwenden, um die Variable SText zu "konvertieren", nachdem sie den Inhalt des jeweiligen Datensatzes zugewiesen bekommen hat, hilft leider nicht weiter, da die Datenbank ja bereits das richtige Format hat. Auch die Umstellung des Compilerflags nutzt in diesem Fall nichts. Auch meine Idee, den Umlautmurks in der CSV per "Strg + F" zu ersetzen, ist hinfällig, da die Umlaute in der CSV-Datei noch korrekt gespeichert sind.
Meine Ansätze zur Lösung des Problems waren bzw. sind folgende:
1. Ich schreibe eine Prozedur, die mittles "FindString" und "ReplaceString" den von SQLite verursachten Umlautmurks bei Einlesen der Datensätze "zurückkonvertiert"; Problem: SQLite speichert jeden Umlaut unter dem selben Ersatzzeichen "? + noch irgendson Mistakronym" ab, eine Rückkonvertierung ist mithin - mangels eindeutiger Zurordnung - nicht möglich.
2. Ich schreibe eine Prozedur, die diese Konvertierung in der CSV-Datei vornimmt und "äöüß " in für SQLite lesbare Zeichen umwandelt und anschließend muss ich im Programm selbst - spiegelbildlich - dazu, eine Rückkonvertierungsprozedur schreiben. Mittlerweile bin ich soweit, dass ich das hinkriegen werde, da ich String-Konvertierungen bei VB hundertmal gemacht hab und diese sich bei PB so gut wie gar nicht von denen in VB unterscheiden.
Ich habe aber ehrlich gesagt, keine Lust, einen solchen Aufwand zu betreiben, der zudem noch die Fehleranfälligkeit des Progs erhöht, da mit jeder Umwandlungsroutine auch eine Fehlerquelle mehr entsteht.
Fällt euch, der ihr mir oftmals geniale Tipps gegeben habt und geholfen habt vor lauter Wald auch mal wieder die Bäume zu sehen, eine bequemere Lösung ein?
Wenn nicht, dann reicht's mir langsam mit dem Aufwand, den ich zur Konvertierung meiner Datenbank von Access in SQLite betreiben muss, ich werd das Thema dann endgültig abhaken und erst, wenn ein "vollautomatisches" Konvertierungsprogramm zur Verfügung steht, mal wieder an SQLite denken. Ich wollte ja auch erst mit meiner Probedatenbank (§ Tabellen) und dem Umlautmurks weitermachen, aber mittlerweile bin ich mit dem Rohgerüst meines User-Interfaces, nicht zuletzt dank eurer Hilfe, fast fertig und ich kann diese verfluchten ? + Hieroglyphen einfach nicht mehr lesen, da werd ich wahnsinnig.
Danke im Voraus!
