Intelligentes Upd.
Systemschlüssel GUID

Allgemeine Hinweise

	Im HIT-Protokoll werden die Aktionen allgemein definiert: Änderungs-Aktionen im "cooked mode": I (INSERT), X (EXECUTE), U (UPDATE),  S (STORNO) und C (CONFIRM)  Änderungs-Aktionen im "raw mode": D (DELETE) sowie die Abfrage-Aktion R (RETRIEVE) als Teil der HIT-QL.
	Eine Übersicht über die allgemeine Bedeutung siehe HIT-Aktionen.
	Die verschiedenen Aktionen bei ADS, siehe ADS-Meldungen.
	Wie sie in einem konkreten Client-Server Kontext benutzt werden, muss fallweise exakt definiert werden.
	Im folgenden werden genaue Verwendungshinweise für die Tierdaten, Betriebsdaten und Systemdaten gegeben.
	Alle 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.
	Die Historisierung von Betriebsdaten kann auch von der ADS in eigener Verantwortung vorgenommen werden.
	Im Normalfall sollten internen Abläufe im Server, z.B. Implementierungsdetails der Historisierung, für den Client transparent sein ("cooked mode").
	In Spezialfällen können Aktionen im "raw mode", insbesondere DELETE, eingesetzt werden. Dann ist eine Kenntnis der Internas und entsprechende Kompetenzen erforderlich.
	Für die Aktionen Execute ("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.
	Ergänzende Hinweise siehe Satzvergleich.
	Zur 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

	Die Aktion INSERT dient bei Tierdaten primär zur Erst-Meldung.
	INSERT ist damit die Standard-Aktion für die Meldepflichtigen.
	Ein Ä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).
	Die 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

	Die 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.
	Die SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
	Es wird geprüft ob aktuelle Sätze (SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen. Wenn 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. Wenn 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. Systemspalten 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.
	Ansonsten werden die Systemspalten gefüllt und der Satz in die Datenbank eingetragen.

Aktion "X" - Execute

Verwendung

	Die Aktion EXECUTE ist nach der allgemeine Spezifikation des HIT-Protokolls geeignet sowohl neue Meldungen einzufügen, wie auch bestehende zu ändern.
	Da 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.
	Die Aktion EXECUTE dient bei Tierdaten damit primär zur Korrektur oder Bestätigung durch die RS.
	Wenn Änderungsmeldungen, selbsttätig vom Meldepflichtigen oder nach Aufforderung zur Korrektur wegen eines Fehler-Vorgangs, zur RS gelangen, können diese Änderungsmeldungen mit EXECUTE in die ZDB gesendet werden.
	EXECUTE ist damit die Standard-Aktion für die RS bei der Meldungs-Nachbearbeitung.
	Wenn 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) Diese 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. Und nur wenn die Nachverfolgung zum Ergebnis gelangt, dass die Daten dennoch korrekt sind oder eine weitere Nachverfolgung wirklich unmöglich ist.
	In der ZDB wird ein eventuell vorhandener alter Satz historisiert und der neue Satz eingefügt.
	Änderungsmeldung bzw. Bestätigungsmeldung können damit an der RS völlig identisch behandelt werden.
	Wenn eine Änderung in Schlüsselfeldern (Primary Key) einer Meldung vorgenommen werden soll, kann EXECUTE nicht verwendet werden. Stattdessen muss die Aktion STORNO zusammen mit der Aktion INSERT verwendet werden. Es existiert alternativ noch die Möglichkeit Globally Unique Identifier (GUID) zu verwenden, Details siehe Systemschlüssel (GUID).
	Ergänzungen hierzu siehe Satzvergleich.

Interner Ablauf

	Die 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.
	Die SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
	Es wird geprüft ob aktuelle Sätze (SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen. Wenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "identical" wenn alter Satz schon bestätigt (STATUS=9) wird nur ein Hinweis (Schwere=1) "already confirmed" ausgegeben. sonst wird der alte Satz über Update TS historisiert, neuer Satz mit STATUS=9 (bestätigt) eingefügt  und Hinweis (Schwere=1) "confirmed" ausgegeben. Wenn nur Systemfelder, wie z.B. Meldeweg anders sind erfolgt eine Nachfrage (Schwere=2) ob der Satz geändert werden soll, d.h. wenn er mit FORCE (/S) gesendet wird, erfolgt eine Änderung andernfalls wird ein Fehler als Nachfrage zurückgegeben. Wenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "duplicate key" vor der alte Satz wird über Update der SYS_BIS-Spalte auf "Current Timestamp" beendet und historisiert neuer Satz mit STATUS=1 (update) eingefügt Hinweis (Schwere=1) "confirmed" wird ausgegeben. sonst wird der Satz normal mit STATUS=0 (neu) in die Datenbank eingetragen und OK (schwere=0) zurückgegeben.
	Der Satz ist für den Client erledigt.
	Bestä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

	Die 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.
	Die Aktion UPDATE ist ansonsten identisch zu EXECUTE und ist damit ebenso geeignet neue Meldungen einzufügen, wie auch bestehende zu ändern.
	Die Aktion ist fast ausschließlich bei Entitäten im Bereich der Adressdaten implementiert.
	Wenn 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.
	Damit ist es möglich den fachlich aktuellen Satz einfach zu ändern.

Interner Ablauf

	Die 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.
	Die SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
	Während der Satzprüfungsphase wird versucht nicht mitgelieferte Felder durch einen eventuell vorhandenen aktuellen Satz zu ergänzen dabei wird der vorhandene Satz über den Primary Key gesucht ist der Primary Key, insbesondere bei Adressdaten nicht vollständig spezifiziert, wird der letzte, "fachlich" aktuellste Datensatz heran gezogen anschließend wird die normale Satzprüfung auch auf Vollständigkeit der Felder fortgesetzt
	Anschließend wird analog zu EXECUTE nochmals geprüft ob aktuelle Sätze (SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen. Wenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "duplicate key" vor der alte Satz wird über Update der SYS_BIS-Spalte auf "Current Timestamp" beendet und historisiert neuer Satz mit STATUS=1 (update) eingefügt sonst wird der Satz normal mit STATUS=0 (neu) in die Datenbank eingetragen und OK (schwere=0) zurückgegeben.
	Der Satz ist für den Client erledigt.

Aktion "S" - STORNO

Verwendung

	Die Aktion STORNO dient bei Tierdaten zum Widerrufen eine früher getätigten, noch aktuellen Meldung.
	Meldepflchtige haben i.d.R. keine Kompetenz und müssen sich an ihre RS wenden.
	Die Aktion STORNO im Verbund mit INSERT dient auch zum Ändern von Daten in Schlüsselfeldern (Primary Key). Es existiert alternativ noch die Möglichkeit Globally Unique Identifier (GUID) zu verwenden, Details siehe Systemschlüssel (GUID).

Interner Ablauf

	Die 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.
	Wenn 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.
	Die SYS_BIS-Spalte darf nicht vom Client gesetzt werden, höchstens auf 31.12.2100 als Standard-Ende-Timestamp.
	Es wird immer die aktuelle Meldung , d.h. mit offenem SYS_BIS-Timestamp storniert. Die Historisierung erfolgt dabei in der ZDB.
	Die SYS_BIS-Spalte wird vom System auf Current Timestamp gesetzt.

Aktion "D" - DELETE

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

Aktion "R" - RETRIEVE

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

Aktion "C" - CONFIRM

Verwendung

	Die Aktion CONFIRM dient zum Bestätigen bereits in der Datenbank gespeicherter Sätze.
	Es ist nur ein gezielter Confirm von, über Primary-Key direkt identifizierter, Datensätze möglich.

	Die allgemeinen Teile des Primary-Key wie Betriebsnummer, Ohrmarke usw. müssen immer angegeben werden.
	Spezielle Teile des internen Primary-Key wie SYS_VON/ SYS_BIS-Timestamp sollten gegeben werden.
	Die Datenteile dienen nur zum Vergleich, müssen aber nicht angegeben werden.

Interner Ablauf

	Die SYS_VON- und SYS_BIS-Spalten dürfen nicht vom Client gesetzt werden.
	Es wird geprüft ob aktuelle Sätze ( SYS_BIS=31.12.2100) mit selbem Key (ohne SYS_VON) vorliegen. Wenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "identical" wenn alter Satz schon bestätigt (STATUS=9) wird nur ein Hinweis (Schwere=1) "already confirmed" ausgegeben. sonst 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. Wenn nur Systemfelder, wie z.B. Meldeweg anders sind erfolgt eine Nachfrage (Schwere=2) ob der Satz bestätigt werden soll, d.h. wenn er mit FORCE (/S) gesendet wird, erfolgt eine Bestätigung andernfalls wird ein Fehler als Nachfrage zurückgegeben. Wenn Sätze vorliegen, diese aber nicht übereinstimmen liegt ein "data changed" vor der Satz wird nicht bestätigt Fehler (Schwere=3) "confirmed" wird ausgegeben. sonst wurde der Satz nicht gefunden und kann damit nicht bestätigt werden und ein Fehler (schwere=3) wird zurückgegeben.
	Bestä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), Execute (X), Storno (S)

Verschiedene Befehls-Subcodes

	/U0 - ohne intelligentes ändern, übernehmen der Datenwerte aus dem vorhandenen Datensatz für nicht angegebene Felder
	/U1 - nur offene hinten anhängen und von hinten stornieren
	/U2 - auch in der Mitte einfügen und in der Mitte stornieren
	/U10 - wie /U0 + /U1
	/U20 - wie /U0 + /U2

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

	wenn noch kein Datensatz vorliegt wird das aktuelle Datum als Gültigkeitsbeginn gewählt
	wenn der neue Datensatz identisch mit dem aktuell gespeicherten ist erfolgt keinerlei Änderung
	wenn der neue Datensatz nicht identisch ist, wird er eingefügt und der aktuelle fachlich abgeschlossen sofern es die erste Änderung des aktuellen Tages ist wird als Gültigkeitsbeginn der aktuelle Tag 00:00h genommen bei 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

	/U1 - einfacher homogene Update, mit Nachfrage (mindestens)
	/U2 - analog U1 ohne Nachfrage, ohne Hinweis
	/U3 - inhomogene Daten, mit Nachfrage (mindestens)
	/U4 - analog U3 ohne Nachfrage, ohne Hinweis
	/U5 - hier auch neue Daten, mit Nachfrage (mindestens)
	/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

	Im Prinzip genauso wie bei Tierbewegungen, aber zusätzlich kann VON- und BIS-Spalte mitgegeben werden.
	Da es keinen gibt der nur INSERT machen darf, kann auch EXECUTE zum Ersteinfügen verwndet werden.
	Wenn 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

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

Aktion "X" - Execute

Verwendung

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

Interner Ablauf

	Wenn 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.
	Die BIS-Spalte wird ggf. auf 31.12.2100 als Standard-Ende-Timestamp gesetzt.
	Es wird geprüft ob aktuelle Sätze (BIS=31.12.2100) mit selbem Key (ohne VON) vorliegen. Wenn 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 ggf. wird eine Fehler (Schwere=3)  "doppelter VON-Timestamp" ausgegeben und die Aktion abgebrochen. Wenn der VON-Timestamp offen, wird "Current TS" angenommen und damit ist Eindeutigkeit i.d.R. gewährleistet. Wenn alle Datenfelder, die aktuell vom Client gesetzt wurden, mit den Felder eines gefundenen Satzes übereinstimmen, ist der Satz "identical". Wenn der BIS-Timestamp gegeben ist und vom vorhandenen Satz abweicht, erfolgt ein Abschließendes aktuellen Satzes, völlig analog zur Aktion STORNO, sonst wird die Meldung ignoriert und ein Hinweis (Schwere=1) "identical" ausgegeben. Wenn ein Satz vorliegt, die Daten aber nicht übereinstimmen ("duplicate key") wird eine historisierende Änderung vorgenommen. Dazu wird der alte Satz über Update der BIS-Spalte auf "Current Timestamp" oder den eventuell gegebenen neuen VON-Timestamp beendet und historisiert und der neue Satz eingefügt sonst 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

	Ein bestehender aktueller Satz wird storniert wenn: der neue Satz ein leeres BIS-Datum hat der neue Satz ein BIS-Datum 31.12.2100 hat der neue Satz ein leeres VOM-Datum hat der neue Satz ein VOM-Datum größer als der aktuelle hat
	Der aktuelle Satz wird nicht abgeschlossen wenn der neue Satz abgeschlossen ist und ein älteres VOM-Datum hat (dann ist er nämlich wahrscheinlich nur "OUT OF ORDER" also falsch sortiert)
	Damit 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

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

Interner Ablauf

	Ist die VON-Spalte gefüllt, so wird nur exakt diese Meldung storniert. Falls diese zwischenzeitlich historisiert geändert wurde, wird der STORNO ignoriert.
	Es wird immer die aktuelle Meldung , d.h. mit offenem BIS-Timestamp storniert.
	Die BIS-Spalte wird vom System auf Current Timestamp oder dem gegebenen BIS-Timestamp gesetzt.
	Gibt 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

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

Aktion "R" - RETRIEVE

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

Aktion "C" - CONFIRM

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

Systemdaten

Aktion "I" - INSERT

	Bei Systemdaten, insbesondere bei LOGON und LOGOFF kann INSERT nicht verwendet werden.
	Stattdessen muss X=Execute benutzt werden (siehe unten)

Aktion "X" - Execute

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

Aktion "S" - STORNO

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

Aktion "U" - UPDATE

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

Aktion "D" - DELETE

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

Aktion "R" - RETRIEVE

	Systemmeldungen LOGON und LOGOFF können nicht abgefragt werden.
	Andere Systemdaten, wie alle Data-Dictionary-Tabellen können abgefragt werden.
	Bei 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

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

Zum Seitenanfang