Update DB nach ALV Änderungen
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
hallo!
ich habe einen ALV grid (cl_gui_alv_grid), kann zwischen ändern und anzeigen freischalten und möchte nachdem änderungen stattgefunden haben und der user auf speichern klickt das ganze auf der datenbank updaten.
wenn ich mich durchdebugge ist in der gt_outtab - also die interne tabelle korrekt gefüllt (mit der methode handle_data_changed realisiert), aber das update schlägt fehl, subrc = 4.
hat wer eine erklärung dafür?
update mache ich mit
update db from table gt_outtab.
ich habe einen ALV grid (cl_gui_alv_grid), kann zwischen ändern und anzeigen freischalten und möchte nachdem änderungen stattgefunden haben und der user auf speichern klickt das ganze auf der datenbank updaten.
wenn ich mich durchdebugge ist in der gt_outtab - also die interne tabelle korrekt gefüllt (mit der methode handle_data_changed realisiert), aber das update schlägt fehl, subrc = 4.
hat wer eine erklärung dafür?
update mache ich mit
update db from table gt_outtab.
Zuletzt geändert von doeme am 03.07.2012 11:16, insgesamt 2-mal geändert.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Fehler im Coding Zeile 227.
Folgende Benutzer bedankten sich beim Autor Unit605 für den Beitrag:
black_adept
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Heißt soviel wie: Wir können nicht hellsehen. Du musst schon etwas mehr posten um den Fehler analysieren zu können.Unit605 hat geschrieben:Fehler im Coding Zeile 227.
Hier eine kleine Anekdote aus der ABAP Hilfe zu sy-subrc = 4 bei UPDATE:
(Vielleicht hilft sie dir ja auch schon weiter)
Ich glaube du versuchst mit dem Update auch neue Zeilen einzufügen bzw. den Schlüssel von vorhandenen Einträgen zu ändern. Das funktioniert so nicht.ABAP Hilfe hat geschrieben:Bei Angabe von SET oder eines Arbeitsbereichs in source wurde keine Zeile geändert oder bei Angabe einer internen Tabelle in source wurden nicht alle angegebenen Zeilen geändert, da entweder keine passende Zeile gefunden wurde oder die Änderung eine Zeile erzeugen würde, die zu doppelten Einträgen im Primärschlüssel bzw. in einem eindeutigen Sekundärindex der Datenbanktabelle führt.
In solchen Fällen musst du wirklich explizit zwischen UPDATE, INSERT und DELETE unterscheiden. SAP kommt dir zumindest bei UPDATE und INSERT mit dem MODIFY-Befehl entgegen. Neue Einträge können damit angelegt und bestehende geändert werden.
Wie gesagt, ich kann nur spekulieren, da ich dein Coding nicht kenne.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
ok - dann bitte um entschuldigung, dass ich das so schwammig formuliert habe.
vlt ist es andersherum produktiver: ich will einfach daten manipulieren in einem ALV grid: bestehende inhalte ändern, zeilen hinzufügen bzw. existierende löschen.
die checks mache ich zB in der methode handle_data_change
wie bekomme ich jetzt geänderte werte in die DB tabelle zurück?
vlt ist es andersherum produktiver: ich will einfach daten manipulieren in einem ALV grid: bestehende inhalte ändern, zeilen hinzufügen bzw. existierende löschen.
die checks mache ich zB in der methode handle_data_change
Code: Alles auswählen.
DATA: ls_good TYPE lvc_s_modi.
FIELD-SYMBOLS: <wa> TYPE ANY,
<feld> TYPE ANY.
*** alle Inhalte der geänderten Zellen in die interne Tabelle schreiben
LOOP AT er_data_changed->mt_good_cells INTO ls_good.
*** Dazu auf die richtige Zeile in der ITAB positionieren:
READ TABLE gt_perlog ASSIGNING <wa> INDEX ls_good-row_id.
IF sy-subrc = 0.
*** Und das geänderte Feld dem Feldsymbol zuweisen
ASSIGN COMPONENT ls_good-fieldname OF STRUCTURE <wa> TO <feld>.
IF sy-subrc = 0.
*** Feldwert zuweisen
<feld> = ls_good-value.
ENDIF.
ENDIF.
ENDLOOP.
CALL METHOD gr_alv->refresh_table_display.
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Damit lag ich dann also richtig:
lg ADT
EDIT: Du musst nur aufpassen, wenn die Daten beim Einlesen von der DB irgendwie gefiltert werden (z.B. mir Selection-Screen), denn dann musst du sicherstellen, dass keine Daten geändert werden die auf der DB noch zusätzlich existieren aber deinem Programm nicht bekannt sind.
EDIT 2: Ich verwende hier mit Absicht die Einzesatzverarbeitung um Fehler besser eingrenzen zu können. Natürlich kann man bei UDATE, INSERT und DELETE auch FROM TABLE verwenden, sofern man etwas mehr Performance braucht und die Daten vorher in entsprechenden internen Tabllen aufgesplitet hat.
Vorschlag wie ich sowas meistens löse:a-dead-trousers hat geschrieben:Ich glaube du versuchst mit dem Update auch neue Zeilen einzufügen bzw. den Schlüssel von vorhandenen Einträgen zu ändern. Das funktioniert so nicht.
In solchen Fällen musst du wirklich explizit zwischen UPDATE, INSERT und DELETE unterscheiden.
- Zwei Tabellen (gt_outab und gt_save)
- In beiden kommen beim Start des Programms dieselben Daten rein
- Alle Änderungen im ALV landen in der gt_outab
- Wenn der Benutzer Speichern möchte, vergleicht man gt_outab und gt_save und schickt die UNTERSCHIEDE an die Datenbank.
Code: Alles auswählen.
loop at gt_outtab assigning <ls_outtab>.
* Kommt der neue Eintrag in der DB überhaupt vor?
read table gt_save assigning <ls_save> with key ... "Der genaue Key muss hier angegeben werden!!!
if sy-subrc ne 0.
* Nein? Dann einfügen
insert ... from <ls_outtab>.
else.
if <ls_outtab> ne <ls_save>.
* Hat sich was verändert?
update ... from <ls_outtab>.
endif.
* Auf alle Fälle aus der Tabelle löschen, damit der REST anschließend von der DB gelöscht werden kann
delete gt_save index sy-tabix. "= sy-tabix von READ TABLE. Aufpassen, dass kein anderer Befehl die sy-tabix verändert.
endif.
endloop.
* Den Rest löschen!
loop at gt_save assigning <ls_save>.
delete ... from <ls_save>.
endloop.
* Die neuen Daten entsprechen nun dem was auf der DB ist!
gt_save = gt_outtab.EDIT: Du musst nur aufpassen, wenn die Daten beim Einlesen von der DB irgendwie gefiltert werden (z.B. mir Selection-Screen), denn dann musst du sicherstellen, dass keine Daten geändert werden die auf der DB noch zusätzlich existieren aber deinem Programm nicht bekannt sind.
EDIT 2: Ich verwende hier mit Absicht die Einzesatzverarbeitung um Fehler besser eingrenzen zu können. Natürlich kann man bei UDATE, INSERT und DELETE auch FROM TABLE verwenden, sofern man etwas mehr Performance braucht und die Daten vorher in entsprechenden internen Tabllen aufgesplitet hat.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Und den Commit am Ende nicht vergessen (falls das nicht schon klar ist):
Ich mache das so:
Ich mache das so:
Code: Alles auswählen.
IF sy-subrc <> 0.
WRITE: 'Fehler beim ...'.
ROLLBACK WORK.
STOP.
ENDIF.
COMMIT WORK.
Gruß
bliss
.|.. .. ...| . .|.. ||| |. ||. .| |. |.. .||. .|. ||| ... .||. . .|.
Ich bin Anfänger und meine Tipps sind mit Vorsicht zu genießen.
bliss
.|.. .. ...| . .|.. ||| |. ||. .| |. |.. .||. .|. ||| ... .||. . .|.
Ich bin Anfänger und meine Tipps sind mit Vorsicht zu genießen.
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
1224
Views
Views
9
Antw.
Antw.
8616
Views
Views
DBTab Update from Table oder in Loop mit "Update Set" Oder ?
von RIG » 09.03.2018 11:27 • Verfasst in ABAP® Core
von RIG » 09.03.2018 11:27 • Verfasst in ABAP® Core
2
Antw.
Antw.
1574
Views
Views
5
Antw.
Antw.
417
Views
Views
15
Antw.
Antw.
8230
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.