SQL Insert schmiert ab

[Fuerchau]

Dabei ist SQL ja so simpel. Von einfach bis komplex ist vieles möglich, inclusive Cubes, Pivot und Unpivot.

[RobertPic]

Der Vollständigkeit halber (auch wenn die Ursache bereits gefunden wurde):

Da es einen Konflikt zwischen 2 Sätzen gibt (einen bestehenden und einen neuen Datensatz), gibt es die Satznummer auch 2x in der Fehlermeldung:


Teildateinummer 1,
Satznummer 1741, Format SAPPRADR, hat den gleichen Schlüssel wie
Teildateinummer 1, Satznummer 0, Format SAPPRADR.

Deshalb hätte man mit
SELECT * FROM SAPBMADR where RRN(SAPBMADR) = 1741

den vorhandenen Satz gefunden.

Das Überprüfen der Daten hilft nur bedingt weiter, weil wie du (@alex61) ja festgestellt hast, sind Kunde vorher nur einmal vorhanden. Sie lassen sich halt nicht nochmal reinschreiben.

[Fuerchau]

Deshalb ist es mit SQL Having-Klausel doch ein wenig schneller.
Und wenn man weiß, dass die Quelle unique ist, muss es am SQL selber liegen.
Und da liegt dann ein 1:N-Join nahe;-).
Problematischer wird die Analyse dann, wenn die Quelle auch noch eine View ist.
Denn das Create View-Statement kann schon mal heftiger sein.

Im Ergebnis wurde ja auch mehr als 1 doppelter Schlüssel gefunden.
Und es hätten da sogar noch wesentlich mehr sein können, was mit der RRN-Methode mühsam geworden wäre. Denn diese ist ja die Satznummer der Ziel-Tabelle.

[RobertPic]

..
Verstehe ich nicht, vor allem was ist die Satznr. 0 ?
...

Wie schon geschrieben, vervollständigte ich die noch offene Frage.

Das man Having ganze Tabellen schneller überprüft ist auch klar. Wobei das Prüfen auf Konflikte von Quell und Zieltabelle noch nicht abgedeckt ist (muss man beim INSERT machen).

Vollständigkeitshalber - Teil 2:
Es gibt auch ein (mühsames) MERGE INTO. Mit dem könnte man z.B. ein Änderungsdatum setzen oder Daten aktualisieren.

https://www.ibm.com/docs/en/i/7.3?topic=language-merging-data

[Fuerchau]

Es ging aber um "in eine leere Zieldatei". Da gibts im Ziel ja vorab nichts zu prüfen.
Satz-Nr. 0 ist eben, dass der einzufügende Satz nun als Dublette auffällt und die Satznummer > 0 eben der bereits aus der Quelle eingefügte Satz.
Wenn man das Ganze jetzt noch unter Commit laufen lässt, ist durch den Absturz das Ziel wieder leer;-).

[BenderD]

Wenn man das Ganze jetzt noch unter Commit laufen lässt, ist durch den Absturz das Ziel wieder leer;-).

... nur wenn man rollback macht und ohne die Möglichkeit des rollback, bleibt eine inkonsistent gefüllte Datei übrig, was beim Bulk insert in nicht leere Dateien hohen Bereinigungsaufwand erfordert.

D*B

[B.Hauser]

... nur wenn man rollback macht und ohne die Möglichkeit des rollback, bleibt eine inkonsistent gefüllte Datei übrig, was beim Bulk insert in nicht leere Dateien hohen Bereinigungsaufwand erfordert.

D*B

Bist Du Dir da so sicher?
Wenn unter Commit gearbeitet wird, erfolgt spätestens beim Job-Ende (oder Ende der Aktivierungsgruppe) egal ob normal oder abnormal (ohne vorheriges Commit) ein Rollback der offenen Transaktionen.

[BenderD]

Bist Du Dir da so sicher?
Wenn unter Commit gearbeitet wird, erfolgt spätestens beim Job-Ende (oder Ende der Aktivierungsgruppe) egal ob normal oder abnormal (ohne vorheriges Commit) ein Rollback der offenen Transaktionen.

... wer füllt schon eine leere Work-Datei und beendet dann den Job, ohne seine Arbeit abgeschlossen zu haben.
Dein Statement kann ich aber so nicht stehen lassen: ENDJOB schickt im default einen Rollback hinterher, RCLACTGRP schickt (idiotischerweise) einen commit hinterher.

D*B