Zur Homepage www.HI-Tier.de NULL/Leerstring
Zurück Home Nach oben Weiter
Öffentlicher Bereich für Entwickler

 

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

bulletentweder als Leerstring <*n:IS:BETRD/NACHNAME;VORNAME;GEB_DAT:Meier;;04.10.1958>
bulletoder 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

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

oder ich müßte beide Methode kombinieren

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

Lösungsvorschläge

1) NULL-Values in String sind verboten

1a) Datenlieferant verantwortlich

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

1b) Datenempfänger verantwortlich

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

2) Leerstring-Values in String sind verboten

2a) Datenlieferant verantwortlich

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

2b) Datenempfänger verantwortlich

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

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

bulletMacht am Server mehr Arbeit.
bulletIch 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.

 

© 1999-2015 Bay.StMELF, verantwortlich für die Durchführung sind die Stellen der Länder , fachliche Leitung ZDB: Frau Dr. Kaja.Kokott@hi-tier.de, Technik: Helmut.Hartmann@hi-tier.de
Seite zuletzt bearbeitet: 29. September 2016 15:38, Anbieterinformation siehe hier im Impressum.