Tipp des Monats für November 2003

Druckversion anzeigen:
	Wussten Sie schon... ?
	... wozu eine Collation Table verwendet wird?
Über (länderspezifische) Sortierung und was uns Unicode bringen würde - Teil 1 Grundlagen In Visual Objects gibt es die Funktion SetCollation(), mit der man die Sortierreihenfolge - für Indexe, aber auch für Arrays - festlegt. In Visual Objects gibt es zwei Einstellmöglichkeiten: #Clipper und #Windows (Voreinstellung). #Clipper wird verwendet, wenn es sich um zu vergleichende Strings im DOS-Zeichensatz handelt. #Windows, wenn ein ANSI-Zeichensatz verwendet wird. Zeichensätze Die DBF speichert die bei der Neuerstellung verwendete Zeichensatz-Einstellung. Dabei wird bei Neuerstellung im DBServer Editor im Export-Dialog das entsprechende Flag gesetzt. Wird eine DBF dynamisch erzeugt, wird die aktuelle Einstellung von SetAnsi() als Zeichensatz-Flag im DBF-Header verwendet. Und zwar hat das erste Byte des Headers den Wert 03h für SetAnsi(FALSE), also OEM-Zeichensatz und 07h für den ANSI-Zeichensatz (die genaue Bit-Belegung für das 1. Byte kann man der Datei RDDAPI.H im VO SDK entnehmen). Da die Spracheinstellungen, die beim Neuanlegen einer DBF vorliegen, für späteres Neuanlegen von Sätzen entscheidend ist, wird im DBF-Header die Codepage codiert (im Byte 30, 1-basiert), die beim Erstellen der DBF vorgelegen hat (weitere Info dazu in der RDDAPI.H des VO SDK). So haben DBFs, die auf einem Rechner mit deutschem Windows von VO bzw. einer VO-Anwendung aus erzeugt wurden, an dieser Stelle entweder den Wert 02h für internationales DOS (Codepage 850) oder 03h für Windows ANSI (Codepage 1252). Jedoch liegt eine Überprüfung, ob immer noch eine Übereinstimmung vorliegt - z.B. wenn die DBF mit deutschen Namen (Achtung Umlaute!) auf einem Rechner mit schwedischem Windows weiter bearbeitet und neue Sätze angehängt werden sollen -, in der Verantwortung des Programmierers. Ein VO RDD und dazugehörige Funktionen tun dies nicht. Sortierung Die im Index verwendete Sortierfolge wird vom DBServer Editor aus im Export-Index-Dialog (Collation-Checkbox) festgelegt. Bei dynamischer Index-Erstellung wird die Einstellung von SetCollation() verwendet. Da die Index-Datei sich diese Einstellung nicht 'merkt', kann es zu korrupten Indexdateien kommen, wenn die SetCollation-Einstellung vor einem neuen Append() geändert wird. Ist die Collation-Einstellung #Windows, werden die LOCALE-Informationen (länderspezifische Einstellungen) von Windows verwendet, um Stringvergleiche und damit Sortierungen vorzunehmen. Ist die Collation-Einstellung #Clipper, wird die im aktiven (per SetNatDLL() eingestellen) VO Nation-Modul enthaltene Collation-Table verwendet. Soweit so gut! Hört sich alles ganz einfach an. Das Problem entsteht jedoch dann, wenn Tabellen Namen (z.B. Nachnamen, Ortsnamen) in den den jeweils nationalen Schreibweisen verwenden sollen. Deshalb hat man ja Unicode erfunden. Aber dazu später. Geänderte Collation Table seit VO-Version 2.5! Insbesondere diejenigen, die gleich von VO 2.0 nach VO 2.6 aufgestiegen sind, haben es vielleicht gar nicht so richtig mitbekommen: Mit der Version Version 2.5 wurde die Windows Collation Table geändert! Hier der übersetzte Abschnitt dazu aus dem Readme zu dieser Version: Geänderte ANSI (Windows) Sortierfolge (Collation Sequences) Die Sortierfolgen wurden in Hinsicht auf Sortierung und Suche von String-Daten verbessert. In VO 2.0 wurden ANSI-String mit Hilfe der "Wort-Sortierung" genannten Technik verglichen. Bei der Wort-Sortierung kommen alle Interpunktionszeichen und nicht alphanumerische Zeichen außer Bindestrich und Apostroph vor allen alphanumerischen Zeichen. Bindestrich und Apostroph werden deshalb anders als andere nicht-alphanumerische Zeichen behandelt, damit Wörter wie "xxrest" und "xx-rest" in einer sortierten Liste aufeinanderfolgen. Dieses Verhalten wurde in VO 2.5 geändert. Strings werden jetzt mit Hilfe der "String-Sortierung" genannten Technik verglichen, in der Bindestrich und Apostroph wie alle anderen nicht-alphanumerischen Zeichen behandelt werden. Diese Änderungen betreffen die ANSI-Sortierfolgen wenn folgende Einstellungen aktiv sind: SetAnsi(.T.) SetCollation(#WINDOWS) Alle ANSI-Indexdateien, die mit Visual Objects 2.0 Anwendungen erstellt wurden, müssen neu erstellt werden, wenn Indexschlüssel Interpunktionszeichen oder andere nicht-alphanumerische Zeichen enthalten. Das folgende Beispiel zeigt das unterschiedliche Verhalten: Die folgende Tabelle zeigt Wörter, die nach beiden Regeln sortiert wurden. VO 2.0 Anwendung VO 2.5 Anwendung oder jünger xx rest xx'rest xx*rest xx-rest xx_rest xx rest xx+rest xx*rest xxarest xx_rest xxbrest xx+rest xxcrest xxarest xx'rest xxbrest xx-rest xxcrest xxrest xxrest xxzrest xxzrest   Ergebnisse von Such-Operationen in beiden Versionen: VO 2.0 Anwendung VO 2.5 Anwendung oder jünger DBSEEK("xx-r") DBSEEK("xx-r") Ergebnis: .T. Ergebnis: .T. gefunden : xx'rest gefunden : xx-rest DBSEEK("xx-") DBSEEK("xx-") Ergebnis: .T. Ergebnis: .T. gefunden : xx rest gefunden : xx-rest Anmerkung: Indexdateien, die keine Interpunktionszeichen und andere nicht-alphanumerische enthalten, oder Indexdateien mit Schlüsseln, die nicht vom Typ String sind, oder OEM-Indexdateien brauchen nicht neu aufgebaut zu werden.   Soweit die Beschreibung der Änderung. Wie man an dieser relativ kleinen Änderung der Collation Table sieht, sind die Auswirkungen in manchen Fällen enorm. Was aber wenn wir Unicode hätten? In Teil 2 lesen Sie: Eine Vorausschau in die Unicode-Welt Das heutige VO und Unicode Zunächst kurz der jetzige Zustand: Das Unicode Debakel Wer braucht überhaupt Unicode? Ausblick Ein paar Quellen zum weiteren Studium
Dieser Tipp stammt von: Dieter Crispien
	Schicken Sie uns Ihren eigenen Tipp des Monats per Email
Druckversion anzeigen:

Letzte Änderung des Inhalts auf dieser Seite: 22.11.03