Zur Homepage www.HI-Tier.de Melden und Korrigieren
Zurück Home Nach oben Weiter
Öffentlicher Bereich für Entwickler

 

Intelligentes Upd.

Allgemeine Hinweise

bulletIm HIT-Protokoll werden die Aktionen allgemein definiert:
bulletÄnderungs-Aktionen im "cooked mode": I (INSERT), X (EXCECUTE), U (UPDATE),  S (STORNO) und C (CONFIRM) 
bulletÄnderungs-Aktionen im "raw mode": D (DELETE)
bulletsowie die Abfrage-Aktion R (RETRIEVE) als Teil der HIT-QL.
bulletEine Übersicht über die allgemeine Bedeutung siehe HIT-Aktionen.
bulletDie verschiedenen Aktionen bei ADS, siehe ADS-Meldungen.
bulletWie sie in einem konkreten Client-Server Kontext benutzt werden, muss fallweise exakt definiert werden.
bulletIm folgenden werden genaue Verwendungshinweise für die Tierdaten, Betriebsdaten und Systemdaten gegeben.
bulletAlle Tier- und Betriebsdaten werden in der ZDB automatisch historisiert, d.h. mit Gültigkeitsbeginn und -ende versehen, so dass später jederzeit eine Datenabfrage zu einem beliebigen Stichtag möglich ist.
bulletDie Historisierung von Betriebsdaten kann auch von der ADS in eigener Verantwortung vorgenommen werden.
bulletIm Normalfall sollten internen Abläufe im Server, z.B. Implementierungsdetails der Historisierung, für den Client transparent sein ("cooked mode").
bulletIn Spezialfällen können Aktionen im "raw mode", insbesondere DELETE, eingesetzt werden. Dann ist eine Kenntnis der Internas und entsprechende Kompetenzen erforderlich.
bulletFür die Aktionen Excecute ("X"), Update ("U") und Storno ("S") zum Ändern und Stornieren von Meldungen sind extra Kompetenzen erforderlich. Diese Kompetenzen hat der Meldepflichtige i.d.R. nicht. Daher müssen Datenänderungen oder Stornierungen immer über die zuständige RS oder Adressdatenstelle erfolgen.
bulletErgänzende Hinweise siehe Satzvergleich.
bulletZur einfacheren Handhabung komplexer Änderungen von Daten mit fachlicher Historisierung, wie den Betriebsdaten BTR_x, Futtermittel und Produktionsrichtung, sowie von Daten mit Intervallsemantik, wie Zahlungsanspruchsdaten ZA_xxx gibt es Unterstützung, Details siehe "Intelligentes Ändern".

Tierdaten

Aktion "I" - INSERT

Verwendung

bulletDie Aktion INSERT dient bei Tierdaten primär zur Erst-Meldung.
bulletINSERT ist damit die Standard-Aktion für die Meldepflichtigen.
bulletEin Ändern von bestehenden Daten ist mit der INSERT-Aktion somit nicht möglich, außer wenn der bestehende Satz gelöscht, storniert oder sein Ende-Datum mit UPDATE auf "nicht mehr aktuell" gesetzt wurde (wozu aber Kompetenzen erforderlich sind die der Meldepflichtige i.d.R. nicht besitzt).
bulletDie gescannten oder anderweitig bei den RS erfassten Meldungen müssen ebenfalls mit INSERT zur ZDB übertragen werden, da sonst der Landwirt unbemerkt Daten ändern könnte.

Interner Ablauf

bulletDie SYS_VON-Spalte darf nicht vom Client gesetzt werden, Historisierung erfolgt nur in der ZDB. Die SYS_VON-Spalte wird vom System auf Current Timestamp gesetzt.
bulletDie SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
bulletEs wird geprüft ob aktuelle Sätze (SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen.
bulletWenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "Identical" und es wird ein Hinweis (Schwere=1) ausgegeben. Der Satz ist für den Client erledigt.
bulletWenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "duplicate key" vor und es wird ein Fehler (Schwere=3) ausgegeben. Der Satz ist für den Client nicht erledigt und muss nachverfolgt werden.
bulletSystemspalten wie Melde-Betrieb, Melde-Datum oder Melde-Weg werden erst seit Hit-Server Version 13 verglichen. Wenn alle User-Daten übereinstimmen, aber Systen-Daten andsers sind erfolgt ein spezielle Hinweis "IdenticalSysDX", weitere Hinweise siehe Satzvergleich.
bulletAnsonsten werden die Systemspalten gefüllt und der Satz in die Datenbank eingetragen.

Aktion "X" - Excecute

Verwendung

bulletDie Aktion EXCECUTE ist nach der allgemeine Spezifikation des HIT-Protokolls geeignet sowohl neue Meldungen einzufügen, wie auch bestehende zu ändern.
bulletDa der normale Meldepflchtige bestehende Tierdaten nicht mehr unmittelbar, sondern nur noch über die RS, ändern darf, erhält er keine Kompetenz für diese Aktion.
bulletDie Aktion EXCECUTE dient bei Tierdaten damit primär zur Korrektur oder Bestätigung durch die RS.
bulletWenn Änderungsmeldungen, selbsttätig vom Meldepflichtigen oder nach Aufforderung zur Korrektur wegen eines Fehler-Vorgangs, zur RS gelangen, können diese Änderungsmeldungen mit EXCECUTE in die ZDB gesendet werden.
bulletEXCECUTE ist damit die Standard-Aktion für die RS bei der Meldungs-Nachbearbeitung.
bulletWenn bestehende Sätze identisch mit "X" nochmals übertragen werden, dient das zur Bestätigung. (diese Funktionalität sollte nicht mehr benutzt werden da sie durch CONFIRM angelöst werden soll)
bulletDiese Bestätigung sollte nur für Meldungen erfolgen, die bereits in der ZDB gespeichert sind, aber aufgrund von "Aposteriori-Prüfungen" als fehlerhaft in einem Fehler-Vorgang angemahnt wurden.
bulletUnd nur wenn die Nachverfolgung zum Ergebnis gelangt, dass die Daten dennoch korrekt sind oder eine weitere Nachverfolgung wirklich unmöglich ist.
bulletIn der ZDB wird ein eventuell vorhandener alter Satz historisiert und der neue Satz eingefügt.
bulletÄnderungsmeldung bzw. Bestätigungsmeldung können damit an der RS völlig identisch behandelt werden.
bulletWenn eine Änderung in Schlüsselfeldern (Primary Key) einer Meldung vorgenommen werden soll, kann EXCECUTE nicht verwendet werden. Stattdessen muss die Aktion STORNO zusammen mit der Aktion INSERT verwendet werden.
bulletErgänzungen hierzu siehe Satzvergleich.

Interner Ablauf

bulletDie SYS_VON-Spalte darf nicht vom Client gesetzt werden, Historisierung erfolgt nur in der ZDB. Die SYS_VON-Spalte wird vom System auf Current Timestamp gesetzt.
bulletDie SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
bulletEs wird geprüft ob aktuelle Sätze (SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen.
bulletWenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "identical"
bulletwenn alter Satz schon bestätigt (STATUS=9) wird nur ein Hinweis (Schwere=1) "already confirmed" ausgegeben.
bulletsonst wird der alte Satz über Update TS historisiert, neuer Satz mit STATUS=9 (bestätigt) eingefügt  und Hinweis (Schwere=1) "confirmed" ausgegeben.
bulletWenn nur Systemfelder, wie z.B. Meldeweg anders sind erfolgt eine Nachfrage (Schwere=2) ob der Satz geändert werden soll, d.h.
bulletwenn er mit FORCE (/S) gesendet wird, erfolgt eine Änderung
bulletandernfalls wird ein Fehler als Nachfrage zurückgegeben.
bulletWenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "duplicate key" vor
bulletder alte Satz wird über Update der SYS_BIS-Spalte auf "Current Timestamp" beendet und historisiert
bulletneuer Satz mit STATUS=1 (update) eingefügt
bulletHinweis (Schwere=1) "confirmed" wird ausgegeben.
bulletsonst wird der Satz normal mit STATUS=0 (neu) in die Datenbank eingetragen und OK (schwere=0) zurückgegeben.
bulletDer Satz ist für den Client erledigt.
bulletBestätigungen werden als separate Sätze gespeichert und nicht nur STATUS geändert damit der Vorgang mit Zeitpunkt und Melder-BNR dokumentiert wird.

Aktion "U" - UPDATE

Verwendung

bulletDie Aktion UPDATE dient zum Ändern von einzelnen Feldern zu Datensätzen mit gegebenem Key, wobei nicht mitgelieferte Felder unverändert, d.h. den aktuell in der ZDB gespeicherten Werte behalten sollen.
bulletDie Aktion UPDATE ist ansonsten identisch zu EXCECUTE und ist damit ebenso geeignet neue Meldungen einzufügen, wie auch bestehende zu ändern.
bulletDie Aktion ist fast ausschließlich bei Entitäten im Bereich der Adressdaten implementiert.
bulletWenn der Primary Key in der Aktion unvollständig angegeben ist, werden im Kontext sinnvolle Ergänzungen vorgenommen, das heißt insbesondere bei den Adressdaten, wo der fachliche Von-Timestamp mit zum PK gehört, manchmal aber lokal nicht unmittelbar bekannt ist, wird der jeweils "jüngste" und fachlich aktuelle Satz heran gezogen.
bulletDamit ist es möglich den fachlich aktuellen Satz einfach zu ändern.

Interner Ablauf

bulletDie SYS_VON-Spalte darf nicht vom Client gesetzt werden, Historisierung erfolgt nur in der ZDB. Die SYS_VON-Spalte wird vom System auf Current Timestamp gesetzt.
bulletDie SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
bulletWährend der Satzprüfungsphase wird versucht nicht mitgelieferte Felder durch einen eventuell vorhandenen aktuellen Satz zu ergänzen
bulletdabei wird der vorhandene Satz über den Primary Key gesucht
bulletist der Primary Key, insbesondere bei Adressdaten nicht vollständig spezifiziert, wird der letzte, "fachlich" aktuellste Datensatz heran gezogen
bulletanschließend wird die normale Satzprüfung auch auf Vollständigkeit der Felder fortgesetzt
bulletAnschließend wird analog zu EXCECUTE nochmals geprüft ob aktuelle Sätze (SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen.
bulletWenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "duplicate key" vor
bulletder alte Satz wird über Update der SYS_BIS-Spalte auf "Current Timestamp" beendet und historisiert
bulletneuer Satz mit STATUS=1 (update) eingefügt
bulletsonst wird der Satz normal mit STATUS=0 (neu) in die Datenbank eingetragen und OK (schwere=0) zurückgegeben.
bulletDer Satz ist für den Client erledigt.

Aktion "S" - STORNO

Verwendung

bulletDie Aktion STORNO dient bei Tierdaten zum Widerrufen eine früher getätigten, noch aktuellen Meldung.
bulletMeldepflchtige haben i.d.R. keine Kompetenz und müssen sich an ihre RS wenden.
bulletDie Aktion STORNO im Verbund mit INSERT dient auch zum Ändern von Daten in Schlüsselfeldern (Primary Key).

Interner Ablauf

bulletDie SYS_VON-Spalte sollte i.d.R. vom Client nicht gesetzt werden, außer Online-Tätigkeiten und Batch-Abläufe bei der RS könnten sich so überschneiden, dass ein online geänderter Satz dann verspätet durch einen Batchjob fälschlich storniert wird. Ist die SYS_VON-Spalte gefüllt, so wird nur exakt diese Meldung storniert. Falls diese zwischenzeitlich historisiert geändert wurde, wird der STORNO ignoriert.
bulletWenn die angegeben User-Daten identisch, aber System-Daten anders sind, kommt es beim Storno zum Fehler der Schwere 2 "StornoDifferentSys" der als Nachfrage erst mittls /S (FORCE) ausgeführt werden kann.
bulletDie SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
bulletEs wird immer die aktuelle Meldung , d.h. mit offenem SYS_BIS-Timestamp storniert. Die Historisierung erfolgt dabei in der ZDB.
bulletDie SYS_BIS-Spalte wird vom System auf Current Timestamp gesetzt.

Aktion "D" - DELETE

bulletDie Aktion DELETE, als vollkommenes Entfernen bestehender Daten ohne Historisierung, ist bei Tierdaten nicht zulässig und damit nicht implementiert.

Aktion "R" - RETRIEVE

bulletDie Aktion RETRIEVE dient allgemein zum Abfragen von Daten.
bulletEs bestehen keine spezifischen Besonderheiten für Tierdaten.

Aktion "C" - CONFIRM

Verwendung

bulletDie Aktion CONFIRM dient zum Bestätigen bereits in der Datenbank gespeicherter Sätze.
bulletEs ist nur ein gezielter Confirm von, über Primary-Key direkt identifizierter, Datensätze möglich.
bulletDie allgemeinen Teile des Primary-Key wie Betriebsnummer, Ohrmarke usw. müssen immer angegeben werden.
bulletSpezielle Teile des internen Primary-Key wie SYS_VON/ SYS_BIS-Timestamp sollten gegeben werden.
bulletDie Datenteile dienen nur zum Vergleich, müssen aber nicht angegeben werden.

Interner Ablauf

bulletDie SYS_VON- und SYS_BIS-Spalten dürfen nicht vom Client gesetzt werden.
bulletEs wird geprüft ob aktuelle Sätze ( SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen.
bulletWenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "identical"
bulletwenn alter Satz schon bestätigt (STATUS=9) wird nur ein Hinweis (Schwere=1) "already confirmed" ausgegeben.
bulletsonst wird im aktuellen der alte Satz über Update TS historisiert, neuer Satz mit STATUS=9 (bestätigt) eingefügt  und Hinweis (Schwere=1) "confirmed" ausgegeben.
bulletWenn nur Systemfelder, wie z.B. Meldeweg anders sind erfolgt eine Nachfrage (Schwere=2) ob der Satz bestätigt werden soll, d.h.
bulletwenn er mit FORCE (/S) gesendet wird, erfolgt eine Bestätigung
bulletandernfalls wird ein Fehler als Nachfrage zurückgegeben.
bulletWenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "data changed" vor
bulletder Satz wird nicht bestätigt
bulletFehler (Schwere=3) "confirmed" wird ausgegeben.
bulletsonst wurde der Satz nicht gefunden und kann damit nicht bestätigt werden und ein Fehler (schwere=3) wird zurückgegeben.
bulletBestätigungen werden als separate Sätze gespeichert und nicht nur STATUS geändert damit der Vorgang mit Zeitpunkt und Melder-BNR dokumentiert wird.

Intelligentes Ändern

Zur einfacheren Handhabung komplexer Änderungen von Daten mit fachlicher Historisierung sowie von Daten mit Intervallsemantik gibt es Unterstützung durch spezielle Befehls-Subcodes /U<z> mit z = 1 bis 6.

Daten mit fachlicher Historisierung

Im ADS-Bereich: BTR_D, BTR_M, BTR_P, BTR_T, BTR_Y, BTR_Z, CC_BESTREG, FM_UN, PROD_RICHT, SZ_PROD

Intelligenz bei den Kommandos Insert (I), Excecute (X), Storno (S)

Verschiedene Befehls-Subcodes

bullet/U1 - nur offene hinten anhängen und von hinten stornieren
bullet/U2 - auch in der Mitte einfügen und in der Mitte stornieren

Daten mit fachlicher Historisierung und automatischer fachlichen Gültigkeit

Es gibt darüber hinaus die Möglichkeit wenn kein fachlicher Gültigkeitsbeginn geliefert wird, dass dieser automatisch "intelligent" ergänzt wird.

Grundsätze

bulletwenn noch kein Datensatz vorliegt wird das aktuelle Datum als Gültigkeitsbeginn gewählt
bulletwenn der neue Datensatz identisch mit dem aktuell gespeicherten ist erfolgt keinerlei Änderung
bulletwenn der neue Datensatz nicht identisch ist, wird er eingefügt und der aktuelle fachlich abgeschlossen
bulletsofern es die erste Änderung des aktuellen Tages ist wird als Gültigkeitsbeginn der aktuelle Tag 00:00h genommen
bulletbei weiteren Änderung innerhalb eines Tages wird die aktuelle Zeit genommen

Siehe dazu "Beispiele für intelligentes Update".

Daten mit Intervallsemantik im ZA-Bereich

Im ZA-Bereich: ZA_AKT_BE,ZA_AKT_BIV,ZA_EIGENT,ZA_GRUND,ZA_NURANG,ZA_NUTZUNG,ZA_PACHT,ZA_PAKET,ZA_ZEITATR

Intelligenz beim Kommando Update (U)

Verschiedene Befehls-Subcodes

bullet/U1 - einfacher homogene Update, mit Nachfrage (mindestens)
bullet/U2 - analog U1 ohne Nachfrage, ohne Hinweis
bullet/U3 - inhomogene Daten, mit Nachfrage (mindestens)
bullet/U4 - analog U3 ohne Nachfrage, ohne Hinweis
bullet/U5 - hier auch neue Daten, mit Nachfrage (mindestens)
bullet/U6 - analog U5 ohne Nachfrage, ohne Hinweis

Betriebsdaten

Da die Adressdaten aber in der Regel eine fachliche Gültigkeit besitzen, die nicht trivial zu handhaben ist, gibt es bei spezielle Befehls-Subcodes zur Unterstützung der komplexen Änderungen, Detail siehe oben bei "Intelligentes Update", 

Achtung: Die nachfolgenden Informationen sind seit der Umstellung der Adressdaten Anfang 2004 hinfällig! 
Die Aktionen verhalten sich bei den Betriebsdaten prinzipiell analog zu den Tierdaten, bieten aber teilweise intelligentes Update!

Bei der Behandlung der Betriebsdaten in den einzelnen ADS und der daraus resultierenden Vorgehensweise beim Übermitteln von Adressdatenänderungen an die ZDB gibt es grob unterschieden 4 Modelle, siehe ADS-Meldungen.

Aktion "I" - INSERT

Verwendung

bulletIm Prinzip genauso wie bei Tierbewegungen, aber zusätzlich kann VON- und BIS-Spalte mitgegeben werden.
bulletDa es keinen gibt der nur INSERT machen darf, kann auch EXCECUTE zum Ersteinfügen verwndet werden.
bulletWenn von der Möglichkeit, eigene, beliebiege Timestamps ins System zu bringen, Gebrauch gemacht wird, ist damit auch eine spezielle Verantwortung für die eigene Historisierung gegeben.

Interner Ablauf

bulletWenn die VON/BIS-Spalten nicht vom Client gesetzt werden, erfolgt Historisierung automatisch in der ZDB. Die VON-Spalte wird dann vom System auf Current Timestamp gesetzt.
bulletDie BIS-Spalte wird ggf. auf 31.12.2100 als Standard-Ende-Timestamp gesetzt.
bulletEs wird geprüft ob aktuelle Sätze (BIS=31.12.2100) mit selbem Key (ohne VON) vorliegen.
bulletWenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "identical"
bulletwenn der BIS-Timestamp gegeben ist und vom vorhandenen Satz abweicht, erfolgt ein Fehler (Schwere=3) "Storno mit INSERT-Aktion nicht möglich".
bulletsonst wird die Meldung ignoriert und ein Hinweis (Schwere=1) "identical" ausgegeben.
bulletWenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "duplicate key" vor. Die neue Meldung wird mit Fehler (Schwere=3) abgelehnt.
bulletsonst ist die Meldung neu und muss eingefügt werden
bulletwenn der VON-Timestamp gegeben ist, prüfe ob nicht ein "duplicate key" vorliegt und gebe ggf. einen Fehler (Schwere=3) "doppelter VON-Timestamp"
bulletsonst wird der Satz in die Datenbank eingetragen und OK (schwere=0) zurückgegeben.

Aktion "X" - Excecute

Verwendung

bulletIm Prinzip genauso wie bei Tierbewegungen, aber zusätzlich kann VON- und BIS-Spalte mitgegeben werden.
bulletEin Mechanismus zur Bestätigung von Adressmeldungen durch mehrfaches identischen Senden besteht nicht
bulletBei identischen Meldungen erscheint immer Hinweis (Schwere=1) "identical" und werder "confirmed" noch "already confirmed"
bulletEXCECUTE ist damit die Standard-Aktion für die ADS zum Einfügen und Ändern.
bulletWenn alle Felder bis auf den BIS-Timestamp indentisch sind bewirkt EXCECUTE ein Storno analog Aktion "S".

Interner Ablauf

bulletWenn die VON/BIS-Spalten nicht vom Client gesetzt werden, erfolgt Historisierung automatisch in der ZDB. Die VON-Spalte wird dann vom System auf Current Timestamp gesetzt.
bulletDie BIS-Spalte wird ggf. auf 31.12.2100 als Standard-Ende-Timestamp gesetzt.
bulletEs wird geprüft ob aktuelle Sätze (BIS=31.12.2100) mit selbem Key (ohne VON) vorliegen.
bulletWenn die VON-Spalte gegeben ist und im weiteren Verlauf ein Speichern des neuen Satzes erfolgen wird, muss zunächst noch geprüft werden, ob dieser Timestamp nicht bereits in der Datenbank vorliegt
bulletggf. wird eine Fehler (Schwere=3)  "doppelter VON-Timestamp" ausgegeben und die Aktion abgebrochen.
bulletWenn der VON-Timestamp offen, wird "Current TS" angenommen und damit ist Eindeutigkeit i.d.R. gewährleistet.
bulletWenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "identical".
bulletWenn der BIS-Timestamp gegeben ist und vom vorhandenen Satz abweicht, erfolgt ein Abschließendes aktuellen Satzes, völlig analog zur Aktion STORNO,
bulletsonst wird die Meldung ignoriert und ein Hinweis (Schwere=1) "identical" ausgegeben.
bulletWenn ein Satz vorliegt, die Daten aber nicht übereinstimmen ("duplicate key") wird eine historisierende Änderung vorgenommen.
bulletDazu wird der alte Satz über Update der BIS-Spalte auf "Current Timestamp" oder den eventuell gegebenen neuen VON-Timestamp beendet und historisiert
bulletund der neue Satz eingefügt
bulletsonst wird der Satz normal in die Datenbank eingetragen und OK (schwere=0) zurückgegeben.

Änderungen Version 12

Seit der Version 12 des HitServers hat es in der Implementation eine geringfügige Änderung ergeben

bulletEin bestehender aktueller Satz wird storniert wenn:
  1. der neue Satz ein leeres BIS-Datum hat
  2. der neue Satz ein BIS-Datum 31.12.2100 hat
  3. der neue Satz ein leeres VOM-Datum hat
  4. der neue Satz ein VOM-Datum größer als der aktuelle hat
bulletDer aktuelle Satz wird nicht abgeschlossen wenn
  1. der neue Satz abgeschlossen ist und ein älteres VOM-Datum hat
    (dann ist er nämlich wahrscheinlich nur "OUT OF ORDER" also falsch sortiert)
bulletDamit ist es jetzt möglich bei XS Werte zu ändern und gleichzeitig einen Storno durch Setzen des Feld für das BIS-Datum xx_BIS durchzuführen.

Aktion "S" - STORNO

Verwendung

bulletIm Prinzip genauso wie bei Tierbewegungen, aber zusätzlich kann BIS-Spalte mitgegeben werden (VON ist bei Tieren auch erlaubt).
bulletDamit kann auch ein STORNO gezielt auf gegebene Timestamp gemacht werden.

Interner Ablauf

bulletIst die VON-Spalte gefüllt, so wird nur exakt diese Meldung storniert. Falls diese zwischenzeitlich historisiert geändert wurde, wird der STORNO ignoriert.
bulletEs wird immer die aktuelle Meldung , d.h. mit offenem BIS-Timestamp storniert.
bulletDie BIS-Spalte wird vom System auf Current Timestamp oder dem gegebenen BIS-Timestamp gesetzt.
bulletGibt der Sender den BIS-Timestamp mit "31.12.2100" als Ende-Datum an, gilt das wie ein nicht mitgegebene BIS-Spalte und es wird auf "Current TS" abgeschlossen.

Aktion "D" - DELETE

bulletDie Aktion DELETE, als vollkommenes Entfernen bestehender Daten ohne Historisierung, ist bei Adressdaten möglich, erfordert aber auch spezielle Verantwortung und Kompetenz.
bulletDie allgemeinen Teile des Primary-Key wie Betriebsnummer, Parent, Child usw. müssen immer angegeben werden.
bulletSpezielle Teile des internen Primary-Key wie VON/BIS-Timestamp sollten gegeben werden um versehentliches Löschen zwischenzeitlich geänderter Datensätze zu verhindern.
bulletDie Datenteile können mitgegeben werden und werden dann in den Vergleich miteinbezogen.

Aktion "R" - RETRIEVE

bulletDie Aktion RETRIEVE dient allgemein zum Abfragen von Daten.
bulletEs bestehen keine spezifischen Besonderheiten für Adressdaten.

Aktion "C" - CONFIRM

bulletNicht verfügbar, Fehler (Schwere=3) "not implemented".

Systemdaten

Aktion "I" - INSERT

bulletBei Systemdaten, insbesondere bei LOGON und LOGOFF kann INSERT nicht verwendet werden.
bulletStattdessen muss X=Excecute benutzt werden (siehe unten)

Aktion "X" - Excecute

bulletEXCECUTE ist damit die Standard-Aktion für LOGON und LOGOFF .

Aktion "S" - STORNO

bulletNicht verfügbar, Fehler (Schwere=3) "not implemented".

Aktion "U" - UPDATE

bulletNicht verfügbar, Fehler (Schwere=3) "not implemented".

Aktion "D" - DELETE

bulletNicht verfügbar, Fehler (Schwere=3) "not implemented".

Aktion "R" - RETRIEVE

bulletSystemmeldungen LOGON und LOGOFF können nicht abgefragt werden.
bulletAndere Systemdaten, wie alle Data-Dictionary-Tabellen können abgefragt werden.
bulletBei der Abfrage dieser Systemdaten ist i.d.R. kein Delta-Transfer möglich, da keine SYS_VON/ SYS_BIS-Timestamps verfügbar sind.

Aktion "C" - CONFIRM

bulletNicht verfügbar, Fehler (Schwere=3) "not implemented".
 

Zum Seitenanfang

 
© 1999-2014 Bay.StMELF, Verantwortlich für Fachfragen: Dr. K.Kokott <mailto:Kaja.Kokott@HI-Tier.de>, Technik: H. Hartmann <mailto:Helmut.Hartmann@HI-Tier.de>
Seite zuletzt bearbeitet: 18. Juli 2014 10:08, Anbieterinformation siehe hier im Impressum.