TRY-CATCH für Blockinsert
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Hallo,
ich arbeite an einer rekursiven Belegflussselektion, die in der 2. Version auch problemlos funktioniert. Der Nachteil ist, dass ich sortierte interne Tabellen mit non-unique key nutze, die ich immer wieder um doppelte Einträge bereinige. Diese Schritt möchte ich eigentlich einsparen.
Ich versuchte eine TRY-CATCH Anweisung, um über die Ausnahmeklasse cx_sy_itab_duplicate_key. Der Insert dient zum Wegschreiben bereits rekursiv bearbeiteter Sätze in eine sortierte unique key Prüftabelle.
Beim Einfügen bekomme ich dann einen DUMP wegen doppelter Schlüssel.
Die grundsätzliche Frage ist erst einmal, wie ich doppelte Schlüssel bei Blockinserts abfangen kann. Bei einem doppelten Schlüssel soll einfach gar nichts geschehen und der nächste Satz prozessiert werden. Sollte die Antwort sein, dass dies nicht möglich ist, frage ich mich, warum im DUMP der Schlüssel angegeben ist, der zu duplikativen Sätzen führt. Daraus folgt für mich, dass diese Sätze sehr wohl erkennbar sind.
LG
ich arbeite an einer rekursiven Belegflussselektion, die in der 2. Version auch problemlos funktioniert. Der Nachteil ist, dass ich sortierte interne Tabellen mit non-unique key nutze, die ich immer wieder um doppelte Einträge bereinige. Diese Schritt möchte ich eigentlich einsparen.
Ich versuchte eine TRY-CATCH Anweisung, um über die Ausnahmeklasse cx_sy_itab_duplicate_key. Der Insert dient zum Wegschreiben bereits rekursiv bearbeiteter Sätze in eine sortierte unique key Prüftabelle.
Code: Alles auswählen.
TRY.
INSERT LINES OF zgt_tb_a_vbfk
FROM zgv_tb_idx0 TO zgv_tb_idx1
USING KEY primary_key
INTO TABLE zgt_tb_h_vbfk.
CATCH cx_sy_itab_duplicate_key INTO oref.
text = oref->get_text( ).
ENDTRY.
Die grundsätzliche Frage ist erst einmal, wie ich doppelte Schlüssel bei Blockinserts abfangen kann. Bei einem doppelten Schlüssel soll einfach gar nichts geschehen und der nächste Satz prozessiert werden. Sollte die Antwort sein, dass dies nicht möglich ist, frage ich mich, warum im DUMP der Schlüssel angegeben ist, der zu duplikativen Sätzen führt. Daraus folgt für mich, dass diese Sätze sehr wohl erkennbar sind.
LG
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Die F1-Hilfe im Editor beschreibt das Verhalten doch ausreichend:3xplor3r hat geschrieben:Die grundsätzliche Frage ist erst einmal, wie ich doppelte Schlüssel bei Blockinserts abfangen kann. Bei einem doppelten Schlüssel soll einfach gar nichts geschehen und der nächste Satz prozessiert werden. Sollte die Antwort sein, dass dies nicht möglich ist, frage ich mich, warum im DUMP der Schlüssel angegeben ist, der zu duplikativen Sätzen führt. Daraus folgt für mich, dass diese Sätze sehr wohl erkennbar sind.
Eine Schleife über die Quell-ITAB und dann jeden Einzelsatz in die Ziel-ITAB einfügen würde das Problem also lösen.F1-Hilfe hat geschrieben: 1. Wenn beim Versuch eine Einzelzeile über den Primärschlüssel einzufügen, Duplikate betreffs des eindeutigen Primärschlüssels entstehen würden, wird keine Zeile eingefügt und sy-subrc auf den Wert 4 gesetzt.
2. Wenn bei einem Versuch eine Einzelzeile über den Schlüssel oder den Index einzufügen, Duplikate betreffs eines eindeutigen Sekundärschlüssels entstehen würden, wird eine behandelbare Ausnahme der Klasse CX_SY_ITAB_DUPLICATE_KEY ausgelöst.
3. Wenn beim Versuch eine einzelne Zeile über einen Index oder mehrere Zeilen als Block einzufügen, Duplikate betreffs eines eindeutigen Primär- oder Sekundärschlüssels entstehen würden, kommt es zu einem Laufzeitfehler.
Gruß Hendrik
Ich wuerde versuchen an dem Punkt anzusetzen, wo die doppelten Saetze in die interne Tabellen kommen und dort erst gar keine doppelten Saetze in die interne Tabelle einfuegen.
Damit hast Du auch den Schritt gespart immer wieder die interne Tabelle um die doppelten Eintraege zu bereinigen.
Warum ist die interne Tabelle ohne unique key? Anscheinend gibt es den doch bzw. koennte es den doch geben?!?!
Damit hast Du auch den Schritt gespart immer wieder die interne Tabelle um die doppelten Eintraege zu bereinigen.
Warum ist die interne Tabelle ohne unique key? Anscheinend gibt es den doch bzw. koennte es den doch geben?!?!
Die F1-Hilfe ist mir des Inhaltes bekannt. Ich habe nach einer Lösungsmöglichkeit gefragt, die es offensichtlich nicht gibt. Ein einzelner Insert ist zu kostspielig.Eine Schleife über die Quell-ITAB und dann jeden Einzelsatz in die Ziel-ITAB einfügen würde das Problem also lösen.
In der Belegflusstabelle sind die Positionen mit hinterlegt. Hier ist eine potentielle Quelle doppelter Schlüssel, die ich mittlerweile über die GROUP BY Klausel ausschließe. Allerdings kann man nicht feststellen, ob bspw. eine Teillieferung, die einen gemeinsamen Auftrag haben, Ergebnis der rekursiven Selektion sind. Daher kann es bei den verschiedenen Durchläufen zu einer Mehrfachselektion bereits selektierter Aufträge und damit zu doppelten Schlüsseln kommen.Ich wuerde versuchen an dem Punkt anzusetzen, wo die doppelten Saetze in die interne Tabellen kommen und dort erst gar keine doppelten Saetze in die interne Tabelle einfuegen.
Damit hast Du auch den Schritt gespart immer wieder die interne Tabelle um die doppelten Eintraege zu bereinigen.
Warum ist die interne Tabelle ohne unique key? Anscheinend gibt es den doch bzw. koennte es den doch geben?!?!
LG
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Weil dir nur das 1. Duplikat angezeigt wird, aber nicht geprüft wird, ob es weitere Duplikate gibt.3xplor3r hat geschrieben:...
Beim Einfügen bekomme ich dann einen DUMP wegen doppelter Schlüssel.
Die grundsätzliche Frage ist erst einmal, wie ich doppelte Schlüssel bei Blockinserts abfangen kann. Bei einem doppelten Schlüssel soll einfach gar nichts geschehen und der nächste Satz prozessiert werden. Sollte die Antwort sein, dass dies nicht möglich ist, frage ich mich, warum im DUMP der Schlüssel angegeben ist, der zu duplikativen Sätzen führt. Daraus folgt für mich, dass diese Sätze sehr wohl erkennbar sind.
So, so. Könntest du mal genauer erläutern, wo du diese Information her hast?3xplor3r hat geschrieben:.... Ein einzelner Insert ist zu kostspielig.
Und warum ein hypothetisch im Kernel implementierter Blockinsert nicht genau das selbe Problem hätte? Denn hier scheinst du bereit solch kostspielige Inserts zu akzeptieren?
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
1765
Views
Views
1
Antw.
Antw.
1063
Views
Views
6
Antw.
Antw.
8171
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.