Z Tabelle Key Feld ändern
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo,
ich habe folgende frage. Bei uns hat sich wegen verschiedener umstände eine Z-Tabelle zerschossen. In dieser Z-Tabelle gibt es ein Key feld welches ich manupulieren müsste. Hierfür habe ich ein kleines Programm geschrieben.
Ich versuche dies über den befehl "Update". Bei nicht Key felder geht dies ohne Probleme. Kann mir jemand helfen, wie ich ein Keyfeld ändern kann. Bei dem Update befehlt bekomme ich dann SY-SUBRC = 4.
Gruß,
Thorsten
ich habe folgende frage. Bei uns hat sich wegen verschiedener umstände eine Z-Tabelle zerschossen. In dieser Z-Tabelle gibt es ein Key feld welches ich manupulieren müsste. Hierfür habe ich ein kleines Programm geschrieben.
Ich versuche dies über den befehl "Update". Bei nicht Key felder geht dies ohne Probleme. Kann mir jemand helfen, wie ich ein Keyfeld ändern kann. Bei dem Update befehlt bekomme ich dann SY-SUBRC = 4.
Code: Alles auswählen.
IF wa_zmerk_p_loesch-atnam = merkmal_name.
wa_zmerk_p_loesch-KDIND = KDIND2.
UPDATE zmerk_p from wa_zmerk_p_loesch.
else.
CONTINUE.Thorsten
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1795 / 213 /
396
)
»
Primärschlüsselfelder kann man nicht ändern, weil sich über diese ja die Tabellenzeile definiert (deswegen ist es ja der Primärschlüssel). Das bedeutet, dass Du die Zeilen nicht änderst, sondern neue anlegst und die alten löschen musst.
Was Du also machen musst, ist ein DELETE der alten Zeile, gefolgt von einem nachfolgenden INSERT der neuen. Am besten danach erst ein COMMIT WORK, damit nicht nach dem DELETE und vor dem INSERT ein Fehler auftreten kann, durch den die Zeile verlorengeht. Erst wenn der INSERT Dir einen SY-SUBRC von Null bringt, machst Du einen COMMIT WORK (oder je nach Umfang des Ganzen auch erst nach mehreren solcher Änderungen, denn nach jedem einzelnen INSERT ein COMMIT WORK gilt als nicht effizient).
Was Du also machen musst, ist ein DELETE der alten Zeile, gefolgt von einem nachfolgenden INSERT der neuen. Am besten danach erst ein COMMIT WORK, damit nicht nach dem DELETE und vor dem INSERT ein Fehler auftreten kann, durch den die Zeile verlorengeht. Erst wenn der INSERT Dir einen SY-SUBRC von Null bringt, machst Du einen COMMIT WORK (oder je nach Umfang des Ganzen auch erst nach mehreren solcher Änderungen, denn nach jedem einzelnen INSERT ein COMMIT WORK gilt als nicht effizient).
Beitrag
von DeathAndPain (Top Expert / 1795 / 213 /
396
)
»
Gern geschehen ("Danke" kann man auch anklicken 
). Vielleicht sollte man noch anmerken, dass die Vorgehensweise mit DELETE und INSERT als Dirty-Variante in einem Pannenfall mal praktikabel sein mag. Wenn Du aber grundsätzlich vor dem Problem stehst, öfter mal Primärschlüsselfelder ändern zu müssen, dann ist das ein ganz starkes Indiz dafür, dass der Primärschlüssel Deiner Tabelle falsch definiert ist.
). Vielleicht sollte man noch anmerken, dass die Vorgehensweise mit DELETE und INSERT als Dirty-Variante in einem Pannenfall mal praktikabel sein mag. Wenn Du aber grundsätzlich vor dem Problem stehst, öfter mal Primärschlüsselfelder ändern zu müssen, dann ist das ein ganz starkes Indiz dafür, dass der Primärschlüssel Deiner Tabelle falsch definiert ist.
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
1991
Views
Views
2
Antw.
Antw.
1327
Views
Views
2
Antw.
Antw.
2187
Views
Views
1
Antw.
Antw.
1396
Views
Views
2
Antw.
Antw.
3123
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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.