COBOL SQL INSERT Satznummer des Inserts

[heg]

Hallo,
im COBOL Programm mit embedded SQL mache ich einen INSERT.
Wenn dieser Insert erfolgreich war benötige ich die Satznummer (RRN(A)) des eingefügten Satzes (am besten als Returnvalue).
Ein nachfolgender SELECT MAX... oder SELECT mit den Werten des INSERTs ist nicht eindeutig genug (das liegt an der Anwendung).
Vielen Dank

[Fuerchau]

Dies ist leider per SQL nicht möglich.
Die Funktion RRN(A) ist ein "kalkuliertes" Ergebnis in SQL auch wenn sich diese RRN außer bei einem RGZPFM ja nie ändert.
Hier hilft wirklich nur eine Identity-Spalte.
Wenn die Tabelle keinen eindeutigen Schlüssel hat, kommst du an diesen Satz nicht mehr dran, schließlich können ja 2 Programme gleichzeitig einen Insert machen.
Und bei einem REUSEDLT(*YES) liefert MAX(RRN(A)) auch nicht den korrekten Wert.

Mittels
select ... from final table (insert into myfile ...)
kann man Feldinhalte die durch Trigger/Defaults gefüllt werden dann wieder auslesen.

Wozu brauchst du die Information denn, wenn du einen Insert machst?

[BenderD]

Dies ist leider per SQL nicht möglich.

... zum Glück! Zum Glück, das ist doch kein Datenschrank-System.

D*B

[B.Hauser]

Sofern man das richtige Release hat und SELECT ... FROM FINAL TABLE absetzen kann, kommt man auch an die entsprechenden relativen Satz-Nr. der eingefügten Sätze.

Select rrn(a), Fld1, Fldx, Fldy, ...
   from Final Table(Insert Into YourTable
                       Select ....
                         From ....
                         Where ....) x
Order By Input Sequence;

Das SELECT-statement (mit samt dem Insert) kann man im DECLARE CURSOR hinterlegen und sich dann durch die einzelnen Sätze loopen.

Das ganze geht natürlich auch bei einem Insert ohne SELECT, also nur über VALUES und aufgelistete Feld-Inhalte.

Ach ja und übrigens, was kaum einer weiß, seit Release 7.1 können auch Indices über die relative Satz-Nr. gebildet werden, was den Zugriff über die relative Satz-Nr. um einiges beschleunigt.

Birgitta

[heg]

Hallo Alle zusammen,
vielen Dank für die Tipps.
Hier noch einige Erklärungen zu Euren Anmerkungen (speziell BenderD):
- Final Table geht leider nicht, da wir gezwungen sind unter V6 zu arbeiten (seufz)
- Einen eindeutigen Satzschlüssel des gerade eingefügten Satzes benötigt man sehr wohl, wenn nach dem Insert eine weitere Funktion sich genau diesem Satz widmen soll, die Schlüsselkomponenten jedoch VOR dem Insert nicht eindeutig sein können (z.B. Timestamp, weshalb ich nach dem INSERT keinen sicheren Select absetzen kann, denn dann müsste ich ja den Timstamp der erzeugt wird vorher wissen) UND die Tabelle von mehreren Programmen asynchron beschrieben werden. In diesem Fall ist es eine Schnittstelle die sowohl von einem Externen System als auch von der I5 beschrieben wird. Schnittstellen werden ein immer größeres Thema.
Gruß
HEG

[BenderD]

- Einen eindeutigen Satzschlüssel des gerade eingefügten Satzes benötigt man sehr wohl, wenn
HEG

Da bin ich (fast) Deiner Meinung: einen eindeutigen Schlüssel braucht man ohne wenn und aber!!!

... genau dafür sind sogenannte Kunstkeys gut (BTW Timestamps taugen nicht als eindeutiger Key, auch nicht in Kombination mit anderen Feldern). Das geht auch in Verbindung mit Identity columns und der Function IDENTITY_VAL_LOCAL (ab welchem Release habe ich nicht im Kopf), mit eigenen generierten Keys geht das immer.

D*B

[heg]

Hallo BenderD,
ich hab IDENTITY_VAL_LOCAL ausprobiert, sieht gut aus und wäre eine Lösung, aber nicht unter V6
(seufz, seufz).
WARUM MÜSSEN SYSTEMENTWICKLER IMMER UNTER VERTRIEBSHEINIES LEIDEN????

HEG

[malzusrex]

Werd im nächsten Leben VERTRIEBSHEINI und lasse deinen SYSTEMENTWICKLER leiden ;-)

[B.Hauser]

IDENTITY_VAL_LOCAL ist auf alle Fälle schon älter als Release 6.1.
Wir setzen es auf alle Fälle unter V5R4 ein (und wenn ich mich recht erinnere hatten wir es bereits unter V5R2 am Laufen).

Ich leide auch noch unter den Altlasten, aber weniger der Vertriebsfuzzis, sondern viel mehr der Wiederstandskraft einiger Kunden gegenüber Neuerungen.
Software-Häuser (sofern sie nicht gerade SAP o.ä heißen) sind am ärmsten dran, wir dürfen/können erst dann eine Stufe höher gehen wenn der letzte Kunde die nächste Stufe erreicht hat.

Birgitta

[BenderD]

... IDENTITY_VAL_LOCAL kam mit V5R2 und davor gab es schon keinen Grund diesen Murks mit RRN zu versuchen (das taugt als Key Kriterium garnichts). Das geht mit einer Kunstkey Spalte und einer UDF GetKey, wie sie auf meiner Freeware Seite zu finden ist, einfach, elegant und schnell. Im Programm erst den Schlüssel holen, sich merken und dann insert.
Ganz am Rande sei vermerkt: wenn ich erst den Satz schreibe, dann noch weitere Werte ermittle und dazu den Satz nochmal lese, dann ist das von rückwärts durch die Brust ins Auge - Programm technische Komplexität ist meistens ein Zeichen für zweitbestes Design. Wobei eine Datei ohne primary Key ist natürlich immer Murks.

D*B

[heg]

Danke, danke für die schnelle Hilfe.
@ B.Hauser Ich werd mich nochmal drum kümmern, vielleicht hab ich ja was falsch gemacht.
@ B.Hauser Bei uns ist das auch so: erst wenn der letzte V5R3M0(!!!) verlassen hat....

@ Admi: Thread kann als gelöst geschlossen werden.