Problem mit COMMIT / ROLLBACK
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Moin,
wir spielen hier gerade am BAL herum und haben "nebenher" eine zusätzliche Clustertabelle fürs BAL. Unser Problem ist: Ich muss nun unabhängig vom Programmlauf Daten in diese Clustertabelle schreiben. Also zum Beispiel lange bevor ich entscheide, ob ein COMMIT WORK oder ein ROLLBACK gemacht werden soll. Ich brauche quasi einen COMMIT WORK ausschließlich für diese Clustertabelle. Mein erster Ansatz war, einen Funktionsbaustein mit STARTING NEW TASK zu feuern, aber der löst leider einen COMMIT WORK in Ursprungsprozess aus (genau das will ich ja verhindern). Ohne diesen COMMIT wäre das genau das, was ich will: Ich starte einen neuen "Prozess", dem ich die Daten übergebe und der schreibt die weg und macht den COMMIT nur für diese Daten. Leider macht der implizite COMMIT mir das alles kaputt, weil dann halbgare Daten in Tabellen geschrieben werden.
Wie kriege ich das hin, dass ich einen COMMIT nur für die Daten erhalte, die in meine Clustertabelle geschrieben werden sollen?
Ralf
wir spielen hier gerade am BAL herum und haben "nebenher" eine zusätzliche Clustertabelle fürs BAL. Unser Problem ist: Ich muss nun unabhängig vom Programmlauf Daten in diese Clustertabelle schreiben. Also zum Beispiel lange bevor ich entscheide, ob ein COMMIT WORK oder ein ROLLBACK gemacht werden soll. Ich brauche quasi einen COMMIT WORK ausschließlich für diese Clustertabelle. Mein erster Ansatz war, einen Funktionsbaustein mit STARTING NEW TASK zu feuern, aber der löst leider einen COMMIT WORK in Ursprungsprozess aus (genau das will ich ja verhindern). Ohne diesen COMMIT wäre das genau das, was ich will: Ich starte einen neuen "Prozess", dem ich die Daten übergebe und der schreibt die weg und macht den COMMIT nur für diese Daten. Leider macht der implizite COMMIT mir das alles kaputt, weil dann halbgare Daten in Tabellen geschrieben werden.
Wie kriege ich das hin, dass ich einen COMMIT nur für die Daten erhalte, die in meine Clustertabelle geschrieben werden sollen?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Mein erster Ansatz wäre, wenn möglich die Operationen auf der Clustertabelle zu sammeln und erst hinter dem Commit WORK oder ROLLBACK WORK tatsächlich auszuführen.
Ein zweiter Ansatz wäre, "Open SQL - Secondary Database Connections". Man kann nämlich auf die SAP-DB auch eine zweite Connection öffnen. Allerdings habe ich das selbst noch nicht gemacht und kann nix zum Aufwand sagen.
Ein zweiter Ansatz wäre, "Open SQL - Secondary Database Connections". Man kann nämlich auf die SAP-DB auch eine zweite Connection öffnen. Allerdings habe ich das selbst noch nicht gemacht und kann nix zum Aufwand sagen.
Service Connections to the SAP Standard Database
In addition to the secondary database connections stored in database table DBCON, service connections to the SAP standard database can also be used. The name of this connection is R/3*name, which consist of the prefix R/3* and a user-defined name. A service connection automatically uses all the settings of the standard database connection.
Notes
Service connections R/3*name can never connect to databases other than SAP standard databases. The freely definable name is not associated with the entries in the database table DBCON and is used only to identify a service connection. Hence, specifying a database connection from the database table DBCON for name does not mean that this database connection is used.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Und bei einem Dump ist alles wegDele hat geschrieben:Mein erster Ansatz wäre, wenn möglich die Operationen auf der Clustertabelle zu sammeln und erst hinter dem Commit WORK oder ROLLBACK WORK tatsächlich auszuführen.
Das mit der Db-Connection sehe ich mir mal an. Danke.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3944 / 105 /
886
)
»
Könnte man dafür evtl. das ABAP Daemon Framework verwenden?
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
7.52, wir arbeiten derzeit auf einem 7.51black_adept hat geschrieben:Könnte man dafür evtl. das ABAP Daemon Framework verwenden?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3944 / 105 /
886
)
»
Dann evtl APC? Die gibt es doch schon länger
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Ich frag mal doof: Wie kommst du auf APC? Welche Idee hast du konkret dazu?black_adept hat geschrieben:Dann evtl APC? Die gibt es doch schon länger
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Das konnte sogar meine geliebte AS400 in den 80ern, zwar lief die Tabelle unter DB-Journal wegen Nachvollziehbarkeit, aber man konnte im Programm explizit die COMMIT-Steuerung für Tabellen unterbinden, das geht bestimmt auch unter Oracle, nur kommt man nicht ran?
Beitrag
von black_adept (Top Expert / 3944 / 105 /
886
)
»
Bei Programmstart einen Channel öffnen und eine Backgroundtask starten welche auf dem Channel lauscht. Dann statt direkter Fortschreibung in die Tabellen die fortzuschreibende Information in den Channel werfen und der Backgroundtask holt sich die Daten und schreibt sie mit Commit work weg. Damit sollte die Fortschreibung von deinem Prozess entkoppelt sein. So zumindest die Idee.ralf.wenzel hat geschrieben:Ich frag mal doof: Wie kommst du auf APC? Welche Idee hast du konkret dazu?
Ralf
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Hast du es schon mal mit SUBMIT versucht? Das sollte keinen impliziten COMMIT auslösen, aber trotzdem eine neue LUW beginnen.ralf.wenzel hat geschrieben:Mein erster Ansatz war, einen Funktionsbaustein mit STARTING NEW TASK zu feuern, aber der löst leider einen COMMIT WORK in Ursprungsprozess aus.
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
Beitrag
von black_adept (Top Expert / 3944 / 105 /
886
)
»
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/de-DE/abapsubmit.htm hat geschrieben:SUBMIT beendet unabhängig vom Zusatz AND RETURN nicht die aktuelle Datenbank-LUW. Ein Datenbank-Commit oder Datenbank-Rollback im aufgerufenen Programm wirkt genauso wie im aktuellen Programm.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
MIST... mir wird grad übelblack_adept hat geschrieben:https://help.sap.com/doc/abapdocu_751_index_htm/7.51/de-DE/abapsubmit.htm hat geschrieben:SUBMIT beendet unabhängig vom Zusatz AND RETURN nicht die aktuelle Datenbank-LUW. Ein Datenbank-Commit oder Datenbank-Rollback im aufgerufenen Programm wirkt genauso wie im aktuellen Programm.
Sch....
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
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Passiert....
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Was hindert dich denn daran, den { Commit | Rollback } auszuführen und danach die Daten in deine (ich frag lieber nicht, warum du eine) Clustertabelle (nimmst...) zu schreiben?
Alternativ hätte ich eine sehr überdimensionierte Idee:
Starte vor Verarbeitung einen Batch job, der mittels AMC auf einem Kanal horcht, ob es Protokolldaten zum Schreiben gibt.
Anstelle des Protokolls schiebst du nun eine AMC-Nachricht an den "Protokollzuhörer", der im Hintergrund läuft. Bin mir nicht 100%ig sicher, ob das klappt, wüsste aber nichts, was dagegen spricht.
Alternativ hätte ich eine sehr überdimensionierte Idee:
Starte vor Verarbeitung einen Batch job, der mittels AMC auf einem Kanal horcht, ob es Protokolldaten zum Schreiben gibt.
Anstelle des Protokolls schiebst du nun eine AMC-Nachricht an den "Protokollzuhörer", der im Hintergrund läuft. Bin mir nicht 100%ig sicher, ob das klappt, wüsste aber nichts, was dagegen spricht.
Vergleichbare Themen
6
Antw.
Antw.
6043
Views
Views
Commit und Rollback, auch bei RFC und BAPI
von m.schwertle » 21.11.2007 08:23 • Verfasst in ABAP® für Anfänger
von m.schwertle » 21.11.2007 08:23 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
3780
Views
Views
Sperrobjekte: Freigeben von Sperren bei Commit/Rollback ?
von MNordlicht » 09.12.2005 13:25 • Verfasst in ABAP® Core
von MNordlicht » 09.12.2005 13:25 • Verfasst in ABAP® Core
11
Antw.
Antw.
7454
Views
Views
1
Antw.
Antw.
1750
Views
Views
2
Antw.
Antw.
1771
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.