Zitat Zitat von Fuerchau Beitrag anzeigen
J
Da es sich hierbei um eine SQL-Funktion handelt, schließt dies RPG/LE (auch CPYF) aus, da man das Feld nicht ausschließen kann.
Wer behauptet denn das schon wieder?
Wir setzten seit Jahren Identity Columns problemlos in Verbindung mit RPG Native I/O und auch bei CPYF mit *MAP *DROP ein.
Der Zähler wird automatisch (korrekt!) generiert, wenn die Identity Column mit GENERATED ALWAYS definiert wurde.

Auch bei native I/O kann man nach dem WRITE den ermittelten Wert der Identity Spalte über die SQL-Funktion IDENTITY_VAL_LOCAL ermitteln.

Bei GENERATED BY DEFAULT wird nur dann weitergezählt, wenn die Identity Column leer ist oder nicht übergeben wurde. Ansonsten wird der in der Variable hinterlegte Wert für die Identity Column übernommen. Damit kann es bei GENREATED BY DEFAULT u.U. zu doppelten Werten kommen. Irgendwann wurde ein neuer Satz wurde mit einem höheren Zähler eingefügt. Beim nächsten Satz ohne Id-Wert wir der automatische Zähler weitergezählt und irgendwann kommt es dann zu Kolision.

Aber auch beim GENERATED ALWAYS kann es zu Duplikaten kommen, nämlich dann, wenn man den Zähler beim Überlauf wieder von vorne anfangen lässt.

Wichtig ist, dass über die Indentity Column entweder ein Key Constraint (Primary oder Unique) oder ein Unique Index definiert wird. Dadurch wird verhindert, dass doppelte Werte eingefügt werden können.

Beim Insert in SQL lässt man entweder die Identity Spalte aus, oder gibt den Sonderwert DEFAULT an.
Sofern man die Identity Spalte mit IMPLICITLY HIDDEN definiert, hat man auch beim Insert aus einer anderen Tabelle keine Probleme, da die Identity Spalte übergangen wird.

Birgitta