Inhaltsverzeichnis

QuIndex

Austausch mit Cindex und Sky

Interessant ist v.a. ein formatierter Austausch.

Sortierte Anzeige und "Verschwinden" von Datensätzen

Wenn beim Kopieren von UT nach UT_sort der Datensatz nach Abschluss der Operation verschwindet (wirkt, wie wenn er gelöscht wurde) oder um mehrere Datensätze nach oben oder unten rutscht, keine Panik: Das kommt daher, dass die Datensätze in einer sortierten Anordnung angezeigt werden. Ab FileMaker 10 führt eine vorliegende Sortierung dazu, dass die Datensätze sofort auf der Basis dieser Sortierung neu einsortiert werden, sobald man etwas sortierrelevantes geändert hat. Eine Änderung an UT_sort ist sortierrelevant, daher die Verschiebung. Will man das verhindern, so muss man vor der Aktion eine unsortierte Anordnung herbeiführen.

Was in QuIndex überprüft werden kann

Die Stärke von QuIndex ist das Überprüfen von datensatzübergreifenden (also eintragsübergreifenden) Eigenschaften der Daten; dazu müssen Datensätze (also Einträge) miteinander verglichen werden. In Cindex und Sky (ebenso in Macrex) gibt es nur wenige Funktionen, die Datensätze miteinander vergleichen:

Diese Vergleichsfunktionenn sind sehr hilfreich und sollten genutzt werden; QuIndex kann dabei kaum helfen (höchstens bei der Verweisprüfung).

QuIndex kann dagegen weitere Vergleiche anstellen, die in Cindex und Sky nicht möglich sind. Dazu zählen:

Beispiel:

Absatz 104, 107
- Absätze zusammenhalten 113
- Absatzkontrolle 112
- Abstand 111
- Ausrichtung 105
- Einzug 106
- Hängender Einzug 108
- Initial 109
- Seitenwechsel 109, 114, 141
- Vertikale Ausrichtung 109
- Zeilen zusammenhalten 113
- Zeilenabstand 111
Absatzabstand 330
Absatzformate 104
Absatzkontrolle 112

Hier gibt es einen Cluster „Absatz“ mit dem Array „Absatz“ und weiteren einzelnen Einträgen außerhalb dieses Arrays. Im Array und außerhalb tauchen die Begriffe „Absatzabstand“ und „Absatzkontrolle“ auf, was natürlich nicht sein darf. Die Bereinigung solcher Fehler trägt wesentlich zur Qualität eines Registers bei. Das bereinigte Register würde folgendermaßen aussehen:

Absatz
- Absätze zusammenhalten 113
- Abstand 111, 330
- Ausrichtung 105
- Einzug 106
- - Erstzeilen- 107
- - hängender 108
- Formate 104
- Initial 109
- Kontrolle 112
- Seitenwechsel 109, 114, 141
- vertikale Ausrichtung 109
- Zeilen zusammenhalten 113
- Zeilenabstand 111

Beispiele: Das obige „Absatz-Beispiel“ zeigt diesen Fall, ein weiteres Beispiel wäre das folgende:

Adiuretin 212–214, 332
– Analoga 150-151, 213–214
– Mangel 399–398
– Sekretion 212-213

Hier hat der Array-Haupteintrag die Seitenverweise 212-214 und 332; ihm folgen aber Untereinträge mit weiteren Seitenverweisen. Weshalb, kann man sich als Leser fragen, gibt es Seitenverweise direkt vom Hauptbegriff Adiuretin aus? Solche Stellen sind zwar nicht grundsätzlich verboten, aber problematisch, weil der Leser vermuten kann, der Indexer hätte sich keine Mühe gegeben, auch die Unterthemen zu den Seitenverweisen im Array-Haupteintrag zu finden. Die Aufgabe für den Indexer wäre also, nachzuschauen, welche Unterthemen evtl. sinnvoll und notwendig sind. Die Bearbeitung könnte auch darauf hinauslaufen, die vorhandenen Unterthemen aufzulösen und alle Seitenverweise direkt hinter dem Array-Haupteintrag zu bringen. Das heißt, diese Art der Bearbeitung trägt ganz wesentlich zur Konsistenz und Benutzerfreundlichkeit eines Registers bei.