KA - keine Angabe

Problem

Beim Senden vom Datensätzen an den HIT-Server, z.B. zum Stornieren oder Updaten mittels Exceute, wird überprüft ob dieser Datensatz so bereits identisch in der Zentrale vorliegt, um dann ggf. Meldungen auszugeben dass der Satz identisch oder anders vorliegt.

Dabei werden alle mitgelieferten Felder verglichen. Wenn nun aber einzelne Felder, wie z.B. die optionalen Felder beim Insert einer GEBURT oder alle Datenfelder außer den Key-Felder bei einem Storno nicht berücksichtig werden sollen muß man diese weglassen.

Dazu kann man selbst jeden Befehl im HIT-Protokoll separat erzeugen, oder beim HitBatch-Client ein eigenes Inputfile mit entsprechend weniger Spalte verwenden.

Lösung

Wenn man aber das selbe Inputfile beim HitBatch verwenden will, muß man die Spalten, die in einzelnen Zeilen nicht berücksichtigt werden sollen, speziell mit KA (keine Angaben) kennzeichnen. Es genügt nicht diese Spalten leer zu lassen, da das ja den Leersting bedeutet.

Wie das im "Strict CSV" bzw. "Readable CSV" zu kodieren ist, siehe CSV-Format

Leerstrings vs. NULL

Problem

ADS (Adressdatenstellen) können Stringvariablen die sie nicht gefüllt haben unterschiedlich liefern

	entweder als Leerstring <*n:IS:BETRD/NACHNAME;VORNAME;GEB_DAT:Meier;;04.10.1958>
	oder als NULL-String <*n:IS:BETRD/NACHNAME;VORNAME;GEB_DAT:Meier;%--;04.10.1958>

Solange Blanks nich signifikant sind gibt es keinen semantischen Unterschied.

Bei der Abfrage nach nicht vorhandenen Stringfeldern müßte ich nun wissen wie die einzelnen ADS in den Ländern die Daten geschickt haben und dann gezielt abfragen

	entweder gegen Leerstring <*n:RS:BETRD/*:VORNAME;EQ;> (ohne Hochkomma im HIT-Protokoll!)
	oder gegen NULL-String <*n:RS:BETRD/*:VORNAME;EQ;%-->

oder ich müßte beide Methode kombinieren

	Kombination <*n:RS:BETRD/*:VORNAME;EQ;;OR;VORNAME;EQ;%-->
	eventuell auch <*n:RS:BETRD/*:VORNAME;IN;;%--> (schwierig umzusetzen)

Lösungsvorschläge

1) NULL-Values in String sind verboten

1a) Datenlieferant verantwortlich

	Die Daten werden werden entsprechen ohne NULLs bei Stringfeldern geliefert.
	Bei der Abfrage wird immer auf Leerstring abgefragt.
	Der Client muß bei einer variablen Selektion den Typ kennen ?!
	Leere Vergleichsfelder müssten je nach Datentyp unterschiedlich umgesetzt werden: bei Numerischem Feld: "BNR15;EQ;%--" (isnull) bei String-Feld: "VORNAME;EQ;" (leer)

1b) Datenempfänger verantwortlich

Der Server setzt NULLs in Strings bei Datenlieferung und bei Retrieve immer in Leerstring um

2) Leerstring-Values in String sind verboten

2a) Datenlieferant verantwortlich

	Die Daten werden werden entsprechen mit NULLs statt Leerstring geliefert.
	Bei der Abfrage wird immer auf NULL abgefragt.

2b) Datenempfänger verantwortlich

	Der Server setzt Leerstring in Strings bei Datenlieferung und bei Retrieve immer in NULLs um.
	Was ist mit Ausgabe ?

3) Client entscheidet per LOGON-Parameter über das Verhalten

	Macht am Server mehr Arbeit.
	Ich mache das nur wenn unbedingt erforderlich!

Comment Niedersachsen

zu Ihrem Problem. Aus unserer Sicht präferieren wir den Lösungsvorschlag 1 = NULL-Values sind in String verboten. Unsere niedersächsische Adreßdatenbank geht derzeit von dieser Konvention aus. Unseren Kunden (Hessen, Rheinland und weitere) werden wir diese Darstellung eindringlich nahelegen.

Aktueller Stand ZDB

Da die meisten ADS sich in derselben Weise geäußert haben, wird davon ausgegangen, dass in Textstrings nicht NULL sondern der Leerstring verwendet wird. NULL-Strings sind zwar erlaubt und möglich, werden aber z.Zt. in der Abfrage nicht unterstützt und können daher nicht explizit in einer Query etwa der Form "RS/BETRD:NAME2:EQ:%--" gesucht.