Daten-Input

<< Click to Display Table of Contents >>

Navigation:  Anhang > Historisches > Handhabung von ASCII-Daten >

Daten-Input

DataFile, InFile

Angabe von ASCII-Inputfiles.

Syntax:

DATAFILE  [ FILEKEY <key> ] [ ALLOWEMPTY ] = <filepath>;
INFILE  [ FILEKEY <key> ] [ ALLOWEMPTY ] = <filepath>;

Es können beliebig viele DATAFILE/INFILE-Statements auftauchen. Alle Eingabedateien werden in der Reihenfolge ihrer Definition nacheinander gelesen und verarbeitet. (Diese Option ist besonders für die Verarbeitung von Wellen usw. gedacht. Um auch unterschiedlich aufgebaute Datensätze in ein Systemfile einlesen zu können, gibt es spezielle Mechanismen der Variablenredefinition und der filespezifischen Rekodierung.)

Beispiel:

DATAFILE = WELLE.1;

DATAFILE = WELLE.2;

DATAFILE = WELLE.3;

usw.

FILEYKEY erlaubt die ausgewählte Zuordnung verschiedener Datensätze (mehrere DATAFILEs, OPENQFILEs und ASSOCFILEs) über mehrere Befragungswellen hinweg (siehe OPENQFILE).

Im DATAFILE/INFILE-Statement können OS-Wildcards genutzt werden, Beispiel:

DATAFILE = "WELLE.*";

Das angegebene Dateiverzeichnis wird nach allen mit dem Namen übereinstimmenden Files durchsucht, die Liste der Dateinamen wird dann alphabetisch sortiert, und alle Dateinamen werden als Inputfiles gespeichert. Wenn also genau WELLE.1, WELLE.2 und WELLE.3 im gegenwärtigen Directory vorhanden wären, wäre also die Wildcard-Formulierung funktionell der oben stehenden Formulierung äquivalent. (ACHTUNG: Vorsicht mit .BAK-Files). Die jeweilige FileNumber ist in der Systemvariablen SystemFileNo abfragbar. Die Zählung ist 1-basiert, d.h. das erste File hat die Nummer 1. Die Dateinamen werden der Variable SystemFileNo als Labels zugeordnet.


Kartennummern

Cards

CARDS teilt mit, aus wie vielen Records bzw. Zeilen ein Fall besteht.

Beispiel:

CARDS = 2;

Voreinstellung ist CARDS=1, d.h. bei Datensätzen, die je Fall aus einer Zeile bestehen, kann man die Spezifikation auch weglassen. Maximalwert ist 2000.

Card

CARD teilt mit, auf welcher Zeile bzw. »Karte« die jetzt folgenden Variablen bzw. das Gewicht zu suchen sind. Ist auf CARD=1 voreingestellt.

CARD und CARDS beziehen sich auf das DATAFILE (und damit automatisch auch auf das COPYFILE).

CardNumber

Syntax:

CARDNUMBER = <STARTCOLUMN> <WIDTH>;

Anweisung, einen einzulesenden Datensatz auf korrekte Kartenreihenfolge zu prüfen. Wenn die Spaltendefinition einer Kartennummer bekannt ist, dann wird dort für die erste Karte immer eine 1, für die zweite eine 2 etc. erwartet. Abweichungen führen zu einem Fehlerprotokoll auf das untere Fehlerfenster im Bildschirm und ggf. ins LISTFILE.


Einlesen offener Fragen

Siehe OpenQFile.


AssertFilterInASCII

Syntax:

ASSERTFILTERINASCII = [ YES | NO ];

Dient der Überprüfung von ASCII-Daten Files auf korrekte Filterführung. Unter der Voraussetzung, dass gefilterte Variablen im Datensatz mit BLANK zu kodieren sind, wird der Datensatz auf Konsistenz geprüft: Input-Felder, die nicht BLANK sind, und die zu Variablen gehören, die nach der Filterstruktur gefiltert sein müssten, führen zu einem Hinweiseintrag in der RTE-Datei.


AssertFilterVars

ASSERTFILTERVARS = <varlist>;

Die hier benannten Variablen (es müssen atomare Variablen sein) werden im ASSERTFILTERINASCII-Output mit ausgegeben.


ZoneInput

Spezielle Input-Anweisung für ASCII-Daten.

Syntax:

ZONEINPUT <varname> = [ MEAN | SUM | COUNT | MIN | MAX ]
<start> <zonewidth> <end>
<varoffset> <varwidth>
{ SELECT <offset> <string> } *n ;

Wenn man Daten hat, in denen häufig strukturell gleiche Informationsblöcke stehen, kann man damit effizient Informationen extrahieren.

Die extrahierbaren Informationen sind MEAN, SUM, COUNT, MIN oder MAX. Es wird optional für beliebig viele SELECT-Klauseln geprüft, ob die betreffende Zone in die Auswertung einbezogen werden soll; mehrere SELECT-Klauseln werden intern durch AND verknüpft. Zum Beispiel:

VARIABLE ZoneMax =;

ZONEINPUT ZoneMax = MAX

11 10 50 // Zonen von 11 bis 50, zonenbreite = 10

0 2

// auszuwertender Inhalt in 11..12, 21..22, 31..32, 41..42

SELECT 2 ’123’;

// Werte nur die Zonen aus mit ’1’, ’2’ oder ’3’ in sp. 13, 23, 33 und 43


Prüfungen und Protokolle

StrictInputCheck

Syntax:

STRICTINPUTCHECK = [ YES | NO ];

Bei der Voreinstellung (YES) wird numerischer Input in einem mehrspaltigen Feld rechtsbündig erwartet; anderenfalls wird ein numerischer Fehler moniert und der Variablenwert auf BLANKVALUE gesetzt. Bei Ausschaltung dieser zusätzlichen Prüfung wird das Inputfeld daraufhin nur daraufhin untersucht, ob eine interpretierbare Zahl vorgefunden wird, und deren Wert wird übernommen, auch wenn sie z.B. linksbündig im Inputfeld steht.

Außerdem wird bei YES verlangt, dass Datenzeilen nicht kürzer sein dürfen, als zur Interpretation des Inputs notwendig ist. Wenn z.B. eine Variable in Sp. 157 stehen soll, eine Zeile aber nur 156 Spalten lang ist, folgt ein Fehler: line too short for input demand. Bei NO wird die Variable auf MISSING gesetzt.

DataErrorDocumentation

Mittels DATAERRORDOCUMENTATION kann man Datensätze auf diese Fehler hin untersuchen.

Syntax:

DATAERRORDOCUMENTATION [ VARIABLES <varlist> ]
[errortype {<errortype>}*n ] = <filename>;

errortype ::= LABELS | RANGE | FILTER | NUMERIC | ALIGN

Von Dritten gelieferte ASCII-Datensätze können im echten Leben viele Fehler enthalten. Einige von diesen sind formal überprüfbar:

LABELS

eine Variable hat einen numerischen Code, für den kein Label existiert

RANGE

der numerische Wert einer Variablen liegt außerhalb des definierten RANGE

FILTER

aufgrund der Setfilter-Anweisungen soll ein Eingabefeld leer sein; es enthält aber Werte 186

NUMERIC

ein Zahlenfeld im input enthält andere Zeichen als Blank . - 0..9.

ALIGN

ein Zahlenfeld im Input steht nicht rechtsbündig

Die Angaben zu VARIABLES und ERRORTYPE sind optional:

Wird VARIABLES nicht gesetzt, dann werden alle Variablen untersucht, die aus dem DATAFILE gelesen werden.

Wird ERRORTYPE nicht gesetzt, dann werden alle oben genannten Fehlermöglichkeiten geprüft.

Als Prüfresultat wird in die Datei <filename> für jeden gefundenen fehler eine Zeile im csv-Format mit der Fehlerbeschreibung ausgegeben. Diese Zeile enthält den Variablennamen, den Fehlertyp, den fehlerhaften Inhalt, die sequentielle Fallnummer und ggf. die Spaltenbelegung im Input-Datensatz.

In einem GESStabs-Lauf können beliebig viele solcher Statements auftauchen, die sinnvollerweise unterschiedliche Dateinamen benennen sollten. Im Normalfall werden ASCII-Datensätze untersucht. einige der Fehlertypen beziehen sich ja direkt auf die Inputfelder: FILTER, NUMERIC und ALIGN. Die Fehlertypen LABELS und RANGE lassen sich aber auf beliebige Variablen beziehen; seien sie aus einem SAV-File gelesen oder aktuell neu berechnet. Auch diese können überprüft werden, wenn man sie in der VARIABLES-Kausel benennt.

Wenn man bei kurzer Prüfung der Ergebnisse feststellt, dass die Ergebnisse für einige Variablen oder einen Fehlertyp nicht aussagekräftig sind, kann man mittels EXCEPT Bereiche ausblenden:

Die EXCEPT-Klausel beinhaltet ein implizites ALL. ERRORTYPE EXCEPT NUMERIC bedeutet sinngemäß "Prüfe alle Errortypes außer NUMERIC".

Zum Beispiel:

DATAERRORDOCUMENTATION

ERRORTYPE EXCEPT NUMERIC FILTER VARIABLES EXCEPT numtest y1 to y11

= filename;

In diesem Fall würden alle Variablen geprüft, die aus dem Input gelesen werden, bis auf "numtest" und die Variablen y1 bis y11. Es würden alle ERRORTYPE geprüft bis auf NUMERIC und FILTER, d.h. die Prüfung erstreckt sich inhaltlich auf LABELS RANGE und ALIGN.