Doppelte Einträge aus einer internen Tabelle löschen anhand einer Bedingung

Re: Doppelte Einträge aus einer internen Tabelle löschen anhand einer Bedingung

Leider fehlt bei Deinem Beispielcode wieder das Wichtigste: Die Typ- und Datendefinitionen. 😢

Damit zusammenhängend ist die Frage, wofür Du diese internen Tabellen so alles brauchst. Davon hängt nämlich ab, welche Tabellenschlüssel Du ihnen verpassen solltest. In Deinen anderen Fragen hast Du immer nur mit Standardtabellen gearbeitet. Spätestens jetzt ist der Zeitpunkt gekommen, sich davon zu verabschieben und Tabellen des Typs SORTED oder gar HASHED zu verwenden.

Ich bin mir zwar nicht ganz sicher, ob bei Delete adjacent dublicates wirklich dann auch immer die Zeile mit dem Status 2 gelöscht wird und nicht plötzlich die mit Status 1.

Das hängt vom Tabellenschlüssel ab. Wenn Du keinen vergibst, vergibt SAP einen Defaultschlüssel, der im wesentlichen alle zeichenartigen Spalten der Tabelle von links nach rechts umfasst. Dein Status 2 wird auch Bestandteil dieses Schlüssels sein. KSCHL ist bei Dir immer 'X' (laut SELECT-Bedingung). Der Fall, dass die Zeile mit dem Status 1 gelöscht wird, kann dann und nur dann passieren, wenn es Zeilen mit demselben OBJKY gibt, bei denen der Status 1 ein größeres ERDAT hat, vorausgesetzt, dass die Reihenfolge der Spalten in Deiner Tabelle dieselbe ist wie in Deinem SELECT-Statement (was ich leider nicht weiß).

Aber selbst, wenn das nicht passieren kann, ist das sehr unschön gelöst. Ein passender, explizit deklarierter Schlüssel wäre besser. Wenn ich mit Standardtabellen arbeite, deklariere ich sie in aller Regel mit dem Zusatz WITH EMPTY KEY, um zu verdeutlichen, dass ich nicht an einer Arbeit mit dubios automatisch vom System erzeugten Defaultschlüsseln interessiert bin. Dann würde ein SORT wie der Deine auch meckern, weil Du ihm nicht gesagt hast, wonach er denn sortieren soll.

Außerdem deutet die Zeile
darauf hin, dass vstat = '0' auch passieren kann. Wenn es '0' und '1' gibt, fliegt '1' raus, logisch, denn der DELETE ADJACENT DUPLICATES behält immer die erste gefundene Zeile.

Ich verstehe sowieso nicht, wozu Du den DELETE ADJACENT DUPLICATES überhaupt brauchst. Du fragst ja im restlichen Programm den VSTAT ohnehin haarklein ab und schmeißt zum Schluss alle, die 0 oder 2 sind, raus.

Und warum eigentlich WHERE vstat = '0' OR vstat = '2', wenn Dein dortiger Kommentartext erklärt, dass Du eigentlich WHERE vstat <> '1' meinst?

Ein LOOP WHERE hat auch miserable Performance, wenn er auf einer Standardtabelle ausgeführt wird. Wenn Du solch LOOP brauchst, ist das ein klares Indiz dafür, dass Du die Tabelle als SORTED definieren solltest. Dann brauchst Du keinen SORT-Befehl mehr, und der LOOP sucht sich performant die benötigten Zeilen heraus (sofern Du in seiner WHERE-Bedingung die Schlüsselfelder der internen Tabelle in der richtigen Reihenfolge angibst und alle bis auf die letzte auf Gleichheit prüfst).

Re: Doppelte Einträge aus einer internen Tabelle löschen anhand einer Bedingung

Hi,

wenn ich die Aufgabe richtig verstehe, geht es darum fehlerhafte Nachrichten zu finden, bzw. eine Liste aller Belege zu erstellen zu denen es keine erfolgreich verarbeitete Nachricht gibt. Ist das soweit richtig verstanden?
Ich persönlich würde das Ganze mit einem Select mit Sub-Query lösen denke ich, ob das die eleganteste Methode ist möchte ich aber nicht bewerten.

Könnte in etwa so gehen:
Achtung nicht getestet da grad kein System greifbar.

Re: Doppelte Einträge aus einer internen Tabelle löschen anhand einer Bedingung

@schick: Sie will ja nicht nur die Fehlerliste, sondern auch die Nutzdaten, um damit weiterzuarbeiten.

@Sonne: Es fehlen die DATA-Deklarationen von p_vbrk und p_nast. Zwar ist zu vermuten, dass diese die von Dir angegebenen Typen tty_vbrk und tty_nast verwenden, aber dann stellt sich die Frage, weshalb Du in Deinem SELECT auch die Spalte PARNR liest, obgleich tty_nast überhaupt kein Feld dafür hat. Außerdem ist in Deinem SELECT kein LIKE drin, weswegen es eigentlich möglich sein sollte, Dir den LOOP zu sparen und performanter mit FOR ALL ENTRIES IN zu arbeiten.

Außerdem halte ich es für problematisch, dass Du zuerst über p_vbrk loopst, um p_nast zu füllen und anschließend dann über p_nast, wobei Du mit den Werten wieder p_vbrk liest. Sollte es zu einem p_vbrk aus irgendeinem Grund - und sei es eine Dateninkonsistenz auf der Datenbank - gar keinen Eintrag in der nast geben, dann führt diese Vorgehensweise dazu, dass die entsprechende p_vbrk-Zeile in Deiner Ergebnistabelle komplett fehlt!

Stattdessen würde ich an Deiner Stelle sagen, Deine Ausgangstabelle ist p_vbrk, und zu deren Sätzen willst Du Informationen beschaffen. Daher würde ich immer von dort aus lesen.

Hier ist ein Vorschlag, wie Du Dein Ziel erreichen kannst, unter der Maßgabe, dass ich Deine Anforderungen richtig verstanden habe:
Dabei bin ich davon ausgegangen, dass Du Gründe hast, ohne FOR ALL ENTRIES IN zu arbeiten (denn das wäre viel schneller und eleganter). Dann brauchst Du den APPENDING TABLE, weswegen Deine Zieltabelle dann nicht SORTED sein kann. Du brauchst sie aber SORTED, da Du sonst nicht effizient darin suchen kannst. Aus diesem Grunde nutze ich hilfsweise eine unsortierte Hilfstabelle, um die Daten darin zusammenzulesen, übertrage den Inhalt dann aber gleich im Anschluss in eine nach Deinen Bedürfnissen sortiert definierte Tabelle (beachte meine geänderte Definition von tty_nast!) und gebe den Speicher der unsortierten Hilfstabelle mit FREE wieder frei. (Den Befehl nutzt kaum einer, aber neben der Speicherersparnis ist er auch für den Leser gut, dem Du damit signalisierst, dass Du diese Tabelle im weiteren Programmverlauf nicht mehr brauchst.)

Dann loope ich wieder über die führende Tabelle p_vbrk und gebe alle Zeilen aus, zu denen es in p_nast keine Entsprechung mit Status 1 gibt. Hierzu nutze ich den Index der sortierten Tabelle p_nast in Verbindung mit dem Konstrukt LINE_EXISTS, das sehr schnell ist. Damit erwische ich auch etwaige Belege, zu denen es in p_nast überhaupt nichts gibt (nach meinem Verständnis wäre das aus Deiner Sicht eine Inkonsistenz und damit auch ein Fehlerfall).

Da Du offenbar hinterher noch Pläne mit den p_nast-Zeilen der korrekt verarbeiteten Belege hast, mache ich dann noch den DELETE WHERE, um den Rest rauszuschmeißen. Fertig.

Und ja warum Delete p_nast where vstat = '0'. or vstat = '2' - weiß ich auch nicht. Es führt doch auch zum Ziel, oder nicht? ;)

Ja, aber:

• Es ist länger.
• Es ist weniger performant (da zwei Prüfungen anstatt einer ausgeführt werden).
• Es ist verwirrend, da Du im Kommentar genau schreibst, was Du machen willst, Dein Code dann aber - ohne Not - etwas anderes macht und der Leser erst darüber nachdenken musst, ob beides logisch äquivalent ist oder nicht

Schlimm ist es trotzdem nicht. Ich wollte es nur erwähnen. Code soll ja das, was Du im Geiste machen möchtest, in Maschinenbefehle gießen. Wenn Du schon explizit für den Leser niederschreibst, was Du tun möchtest, sollte der Code optimalerweise genau das widerspiegeln.