Batch-Input für Aufträge
3 Beiträge
•
Seite 1 von 1
3 Beiträge
Seite 1 von 1
Hallo Leutz,
ich habe ein Problem bei einem Batch-Input.
Dieser Batch wird durch ein COMMIT WORK im Programm SAPMV45A / MV45AFZZ form userexit_read_document.
abgebrochen. Ich weiß leider nicht, ob dies wirklich eine User-Modifikation ist.
Hat jemand eine Idee, wie ich dies umgehen kann ?
Ich muß für mehrere Programme Daten im Auftrag ändern. Gibts einen anderen Weg ?
MfG
CP
ich habe ein Problem bei einem Batch-Input.
Dieser Batch wird durch ein COMMIT WORK im Programm SAPMV45A / MV45AFZZ form userexit_read_document.
abgebrochen. Ich weiß leider nicht, ob dies wirklich eine User-Modifikation ist.
Hat jemand eine Idee, wie ich dies umgehen kann ?
Ich muß für mehrere Programme Daten im Auftrag ändern. Gibts einen anderen Weg ?
MfG
CP
It's real, it's true, it's me !
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Wenn im USEREXIT_READ_DOCUMENT ein COMMIT WORK vorkommt, ist das mit Sicherheit nicht von SAP gekommen.
SAP liefert die FORMs leer aus.
COMMIT WORK in einem Userexit ist sowieso eine schlechte Idee.
Ich weiß ja nicht, warum das COMMIT WORK dort steht.
Werden USEREXIT_READ_DOCUMENT direkte DB-Änderungen an SAP-Standard-Tabellen vorgenommen? Auch keine so gute Idee.
Eventuell kann man die Anweisung ja inändern.
Oder werden in dem Userexit andere FBs mit CALL FUNCTION ... IN UPDATE TASK aufgerufen?
Hat mal jemand überprüft, ob nach dem COMMIT WORK die Sperreinträge noch da sind?
Wenn Du CALL TRANSACTION ... USING ... nutzt, kann man per Zusatz OPTIONS auch festlegen, dass die Transaktion bei COMMIT WORK nicht beendet werden soll.
(Dann musst Du aber vermutlich noch ein Dynpro mehr in der itab übergeben...)
SAP liefert die FORMs leer aus.
COMMIT WORK in einem Userexit ist sowieso eine schlechte Idee.
Ich weiß ja nicht, warum das COMMIT WORK dort steht.
Werden USEREXIT_READ_DOCUMENT direkte DB-Änderungen an SAP-Standard-Tabellen vorgenommen? Auch keine so gute Idee.
Eventuell kann man die Anweisung ja in
Code: Alles auswählen.
CALL FUNCTION 'DB_COMMIT'.Oder werden in dem Userexit andere FBs mit CALL FUNCTION ... IN UPDATE TASK aufgerufen?
Hat mal jemand überprüft, ob nach dem COMMIT WORK die Sperreinträge noch da sind?
Wenn Du CALL TRANSACTION ... USING ... nutzt, kann man per Zusatz OPTIONS auch festlegen, dass die Transaktion bei COMMIT WORK nicht beendet werden soll.
(Dann musst Du aber vermutlich noch ein Dynpro mehr in der itab übergeben...)
Hallo Frank,
leider gibt es bei mir scheinbar diesen Zusatz noch nicht. Version 3.1I.
Im Exit wird der FB's STATUS_OBJECT_CREATE über den
Belegkopf und die Positionen genutzt. Der Sinn verschliesst sich mir noch.
Mal schauen was da so gemacht wird...
Gruß
CP
leider gibt es bei mir scheinbar diesen Zusatz noch nicht. Version 3.1I.
Im Exit wird der FB's STATUS_OBJECT_CREATE über den
Belegkopf und die Positionen genutzt. Der Sinn verschliesst sich mir noch.
Mal schauen was da so gemacht wird...
Gruß
CP
It's real, it's true, it's me !
Seite 1 von 1
Vergleichbare Themen
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 4 Stunden von DSHSHCMSUPP 3 / 428
vor 4 Stunden von DSHSHCMSUPP 3 / 428
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 4 Stunden von DSHSHCMSUPP 3 / 428
vor 4 Stunden von DSHSHCMSUPP 3 / 428