"Sicheres" Insert in DB Tabelle
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo,
ich würde gerne eine "sicheres" Insert in eine Datenbanktabelle machen. Da es sich um wichtige Produktionsdaten handelt, dürfen diese Daten nicht verlohren gehen.
Was für Möglichekeiten gibt es, eine Datenbanktabelle und das Insert in diese "sicher" zu machen?
Beim Insert habe ich nach dem Schreiben gleich noch einmal ein Select gemacht, um sicherzugehen, dass die Daten auch wirklich in der DB vorhanden sind:
In meiner Testanwendung mit 10 Anträgen funktioniert das auch alles. Nur ist die Frage, ob es im grossen auch funktioniert bzw. wie man die Tabelle so konfiguriert, dass es funktioniert.
Ich hoffe ihr könnt mir weiterhelfen.
Gruss
DonOssi
ich würde gerne eine "sicheres" Insert in eine Datenbanktabelle machen. Da es sich um wichtige Produktionsdaten handelt, dürfen diese Daten nicht verlohren gehen.
Was für Möglichekeiten gibt es, eine Datenbanktabelle und das Insert in diese "sicher" zu machen?
Beim Insert habe ich nach dem Schreiben gleich noch einmal ein Select gemacht, um sicherzugehen, dass die Daten auch wirklich in der DB vorhanden sind:
Code: Alles auswählen.
ls_antr-xml = iv_xml.
INSERT INTO Tabelle VALUES ls_antr.
IF sy-subrc NE 0.
" TODO Fehlermeldung
ENDIF.
CLEAR ls_antr.
*************Nochmals prüfen, ob der Datensatz wirklich in der Tabelle vorhanden ist
SELECT * FROM Tabelle INTO ls_antr WHERE antragsid = iv_id .
IF ls_antr-xml = lv_xml .
select_erfolgreich = 'X'. " boolean
ENDIF.
ENDSELECT.
IF select_erfolgreich = 'X'.
" TODO weitere Bearbeitung anstossen, welche nichts mit den DB einträgen zu tun hat
ELSE.
" TODO Fehlermeldung, wenn Datensatz nicht in Tabelle gefunden werden konnte
ENDIF.
Ich hoffe ihr könnt mir weiterhelfen.
Gruss
DonOssi
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4098 / 128 /
941
)
»
Hallo DonOssi,
ist das nicht ein wenig paranoid? Du bekommst doch einen sy-subrc ob der Insert geklappt hat. Und dieser Sy-Subrc wird de facto von der DB hochgereicht.
Wenn die DB also der Meinung ist, dass der Datensatz erfolgreich eingefügt wurde verlasse ich mich üblicherweise ( auch in Produktivsystemen ) auf diese Antwort.
Davon abgesehen ist auch dein nachfolgender Select nicht aussagekräftig, solange du keinen Commit vorher absetzt.
ist das nicht ein wenig paranoid? Du bekommst doch einen sy-subrc ob der Insert geklappt hat. Und dieser Sy-Subrc wird de facto von der DB hochgereicht.
Wenn die DB also der Meinung ist, dass der Datensatz erfolgreich eingefügt wurde verlasse ich mich üblicherweise ( auch in Produktivsystemen ) auf diese Antwort.
Davon abgesehen ist auch dein nachfolgender Select nicht aussagekräftig, solange du keinen Commit vorher absetzt.
Spiel mir das Lied vom Tod hat geschrieben: Soll ich einem Mann trauen, der sich'n Gürtel umschnallt und außerdem Hosenträger hat? Einem Mann, der noch nicht mal seiner eigenen Hose vertraut?
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Dem kann ich nur beipflichten!black_adept hat geschrieben:Davon abgesehen ist auch dein nachfolgender Select nicht aussagekräftig, solange du keinen Commit vorher absetzt.
Die Daten sind zu INSERT-Zeitpunkt nur in der Transaktion vorhanden, aber noch lang nicht auf der DB.
Wichtiger als ein "sicheres Insert" ist eher ein durchdachtes Transaktionsdesign:
Z.B.: Lesen aus Tabelle A --> Ändern in Tabelle A --> Änderung in Tablle B aufgrund von A --> Änderung in Tabelle C protokollieren.
Und noch vor dem dritten Schritt vertschüsst sich dein Programm (zuwenig Speicher usw.)
Eigentlich handelt es sich ja um eine durchgängige Transaktion, d.h. ALLE Schritte werden benötigt (denk nur mal an eine Überweisung von deinem Bankkonto auf ein anderes)
Wenn man nach dem zweiten Schritt schon das COMMIT machen würde, wäre nur die halbe Transaktion gut gegangen. Sprich du hast kein Geld mehr auf dem Konto, aber der Empfänger hat auch nichts bekommen.
Wichtig ist noch zu erwähnen, dass SAP automatisch bei gewissen Aktionen (DYNPRO-Wechsel, Transaktionsaufruf) ein implizites COMMIT durchführt und somit alle INSERTs, UPDATEs und DELETEs damit an die DB überträgt.
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
Ist es den Sinnvoll nach dem Insert ein explizites Commit mitzugeben oder macht SAP das beim verlassen einer Klassenmethode automatisch?
Eine Abhängigkeit zu anderen Tabellen wird es zumindestens aus jetiger Sicht nicht geben.
Eine Abhängigkeit zu anderen Tabellen wird es zumindestens aus jetiger Sicht nicht geben.
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hi!
Wenn danach noch etwas kommt, dass uU Auswirkungen auf die Verarbeitung hat (evtl. Kurzdump im CFW) wäre ein explizites COMMIT sicher sinnvoll.
Aber bitte nicht nach jedem Einzelsatz sondern erst wenn die ganzen Daten weg sind. Sonst wirst du deine liebe Freude mit dem Systembetrieb (bzw. Sysadmin oder wie das bei euch heißt) bekommen, da die Achive-Logs überlaufen. (Hatte ich schon mal
)
Bei Methoden wird übrigens kein implizites COMMIT ausgelöst.
Das passiert nur bei Aktionen die einen Bildschirmwechsel verursachen (CALL TRANSACTION, SUBMIT, CALL SCREEN usw)
Deshalb kann man auch nur in WebDynpros mit den sog. persistenten Objekten arbeiten (= Abbildung einer DB-Tabelle in ABAP ähnlich zu SDO, JDO, usw).
lg
ADT
Wenn danach noch etwas kommt, dass uU Auswirkungen auf die Verarbeitung hat (evtl. Kurzdump im CFW) wäre ein explizites COMMIT sicher sinnvoll.
Aber bitte nicht nach jedem Einzelsatz sondern erst wenn die ganzen Daten weg sind. Sonst wirst du deine liebe Freude mit dem Systembetrieb (bzw. Sysadmin oder wie das bei euch heißt) bekommen, da die Achive-Logs überlaufen. (Hatte ich schon mal
)Bei Methoden wird übrigens kein implizites COMMIT ausgelöst.
Das passiert nur bei Aktionen die einen Bildschirmwechsel verursachen (CALL TRANSACTION, SUBMIT, CALL SCREEN usw)
Deshalb kann man auch nur in WebDynpros mit den sog. persistenten Objekten arbeiten (= Abbildung einer DB-Tabelle in ABAP ähnlich zu SDO, JDO, usw).
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
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
3143
Views
Views
5
Antw.
Antw.
2735
Views
Views
2
Antw.
Antw.
2361
Views
Views
Datenbanktabelle auffüllen aus interner Tabelle mit Insert
von Nourie » 16.08.2005 15:29 • Verfasst in ABAP® für Anfänger
von Nourie » 16.08.2005 15:29 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
9899
Views
Views
INSERT / MODIFY auf Z-Tabelle mit/ohne Commit-Work ?
von gre » 19.11.2007 16:08 • Verfasst in ABAP® für Anfänger
von gre » 19.11.2007 16:08 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
1454
Views
Views
LSMW - Fehler bei Update, Insert or Delete der Tabelle MLAN
von strobbel » 24.07.2008 11:21 • Verfasst in ABAP® für Anfänger
von strobbel » 24.07.2008 11:21 • Verfasst in ABAP® für Anfänger
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.