Sperre geht verloren (Hintergrundmodus) ENQUEUE_E_TABLE
Hallo,
hat jemand eine Idee, warum mein Sperreintrag verloren geht? Dies tritt nur im Hintergrundmodus auf. Die Sperre ist kurz da (SY-SUBRC 0) - und verschwindet kurz darauf wieder. Es wird jedoch kein DEQUEUE ausgelöst...
viele Grüße und vielen Dank...
Alex
hat jemand eine Idee, warum mein Sperreintrag verloren geht? Dies tritt nur im Hintergrundmodus auf. Die Sperre ist kurz da (SY-SUBRC 0) - und verschwindet kurz darauf wieder. Es wird jedoch kein DEQUEUE ausgelöst...
viele Grüße und vielen Dank...
Alex
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi Alex,
weil dein Programm beendet ist...?
Die Sperre wird autom. aufgehoben, sobald die Transaktion beendet ist.
Gruß, Enno
weil dein Programm beendet ist...?
Die Sperre wird autom. aufgehoben, sobald die Transaktion beendet ist.
Gruß, Enno
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Warum ENQUEUE_E_TABLE?
Was für ein Objekt sperrst Du damit?
Wenn die Sperre mit Defaultwert für _SCOPE geholt wird, wird sie bei COMMIT WORK an den Verbucher übergeben, wenn da vorher ein CALL FUNCTION ... IN UPDATE TASK prozessiert wurde.
Wenn dann die V1-Verbuchung fertig (oder abgebrochen) ist, wird die Sperre vom Verbucher freigegeben.
Ausweg:
Entweder _SCOPE = 3 beim ENQUEUE (d,h. sowohl Verbucher als auch Dein Programm müssen die Sperre freigeben) oder zu Anfang ein SET UPDATE TASK LOCAL.
Was für ein Objekt sperrst Du damit?
Wenn die Sperre mit Defaultwert für _SCOPE geholt wird, wird sie bei COMMIT WORK an den Verbucher übergeben, wenn da vorher ein CALL FUNCTION ... IN UPDATE TASK prozessiert wurde.
Wenn dann die V1-Verbuchung fertig (oder abgebrochen) ist, wird die Sperre vom Verbucher freigegeben.
Ausweg:
Entweder _SCOPE = 3 beim ENQUEUE (d,h. sowohl Verbucher als auch Dein Programm müssen die Sperre freigeben) oder zu Anfang ein SET UPDATE TASK LOCAL.
Hallo vielen Dank soweit,
der Report ist leider nicht beendet - er ist noch aktiv.
Er darf nur 1x laufen. Daher lege ich mit dem o.g. Baustein eine Sperre an, worauf bei Programmbeginn geprüft wird, ob diese existiert. Wenn ja, soll der Report mit einer Meldung beendet werden. Dies lief auch eine Zeit wunderbar. Nur durch Zufall wurde entdeckt, dass es auf einmal nicht mehr läuft.
CALL FUNCTION 'ENQUEUE_E_TABLE'
EXPORTING
tabname = SY-REPID
varkey = lf_varkey
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
* Fehler - Report läuft bereits: einfacher Write
WRITE: /,text-pru.
ENDIF.
vielen Dank soweit - weitere Ideen?
Alex
der Report ist leider nicht beendet - er ist noch aktiv.
Er darf nur 1x laufen. Daher lege ich mit dem o.g. Baustein eine Sperre an, worauf bei Programmbeginn geprüft wird, ob diese existiert. Wenn ja, soll der Report mit einer Meldung beendet werden. Dies lief auch eine Zeit wunderbar. Nur durch Zufall wurde entdeckt, dass es auf einmal nicht mehr läuft.
CALL FUNCTION 'ENQUEUE_E_TABLE'
EXPORTING
tabname = SY-REPID
varkey = lf_varkey
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
* Fehler - Report läuft bereits: einfacher Write
WRITE: /,text-pru.
ENDIF.
vielen Dank soweit - weitere Ideen?
Alex
Hi Alex,
abgesehen davon, dass SY-REPID sich bei der Übergabe an den Funktionsbaustein ändert und daher nicht so angebracht ist für deinen Zweck, wüsste ich aber auch nicht, was ansonsten die Sperre auflösen sollte...
Mit SY-REPID sperrst du sozusagen, das Rahmenprogramm vom FB 'ENQUEUE_E_TABLE'. Solange das nur einmal passiert ist es ja auch egal, weil das Programm ja trotzdem die gleiche Sperre abfragt.
Ansonsten kann ich mir durchaus vorstellen, dass der Prozess, der für's Sperren zuständig ist, vielleicht irgendwelche "Macken" hat. Ich meine, es gab früher mal ein Problem, bei irgendeiner Konstellation von mehreren Applikationsservern...
oder so ähnlich. -> OSS?
Geht die Sperre nur bei diesem einen Programm verloren?? wie lange läuft es? Kannst du das mit einem Testprogramm nachvollziehen?
Gruß, Enno
abgesehen davon, dass SY-REPID sich bei der Übergabe an den Funktionsbaustein ändert und daher nicht so angebracht ist für deinen Zweck, wüsste ich aber auch nicht, was ansonsten die Sperre auflösen sollte...
Mit SY-REPID sperrst du sozusagen, das Rahmenprogramm vom FB 'ENQUEUE_E_TABLE'. Solange das nur einmal passiert ist es ja auch egal, weil das Programm ja trotzdem die gleiche Sperre abfragt.
Ansonsten kann ich mir durchaus vorstellen, dass der Prozess, der für's Sperren zuständig ist, vielleicht irgendwelche "Macken" hat. Ich meine, es gab früher mal ein Problem, bei irgendeiner Konstellation von mehreren Applikationsservern...
oder so ähnlich. -> OSS?Geht die Sperre nur bei diesem einen Programm verloren?? wie lange läuft es? Kannst du das mit einem Testprogramm nachvollziehen?
Gruß, Enno
Hallo vielen Dank,
die variable mit repid hab ich nur hier umbenannt - sie wird nicht dynamisch gezogen. Hier das Coding - bevor ihr auf die Idee kommt: Nein, das Dequeue wird nicht ausgelöst - das würde man im Joblog sehen...
Meine Vermutung zielt auch eher auf ein tieferes Problem. Im Entwicklungs- & Konsolidierungssystem tritt der Fehler nicht auf. Seltsam ist, dass im Onlinemodus alles glatt läuft?
START-OF-SELECTION.
PERFORM running CHANGING lf_exit. "lauf ich schon?
IF lf_exit NE 0.
EXIT.
ENDIF.
PERFORM check_datarows CHANGING lf_exit. "sind Daten in den Tabellen? (lediglich select)
IF lf_exit NE 0.
PERFORM dequeue. "den Sperreintrag wieder raus!
EXIT.
ENDIF.
PERFORM read_and_excecute."ausführen
PERFORM dequeue. "den Sperreintrag wieder raus!
PERFORM output. "Kurzer Status zum Schluss
END-OF-SELECTION.
FORM running changing pf_exit like sy-subrc.
* 1. Laufe ich schon?
* Wenn Nein: Sperreintrag!
CALL FUNCTION 'ENQUEUE_E_TABLE'
EXPORTING
tabname = lf_repid
varkey = lf_varkey
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
* Fehler - Report läuft bereits: einfacher Write
WRITE: /,text-pru.
ENDIF.
pf_exit = sy-subrc.
* &1 &2
MESSAGE i043(zxxxi) WITH text-hm1 sy-subrc.
ENDFORM. " running
FORM dequeue .
* entsperren - Transaktion kann wieder genutzt werden...
CALL FUNCTION 'DEQUEUE_E_TABLE'
EXPORTING
* MODE_RSTABLE = 'E'
tabname = lf_repid
varkey = lf_varkey
* X_TABNAME = ' '
* X_VARKEY = ' '
* _SCOPE = '3'
* _SYNCHRON = ' '
* _COLLECT = ' '
.
* & & & &
MESSAGE i170(zxxx) WITH text-hm2 sy-datum sy-uzeit.
ENDFORM. " dequeue
die variable mit repid hab ich nur hier umbenannt - sie wird nicht dynamisch gezogen. Hier das Coding - bevor ihr auf die Idee kommt: Nein, das Dequeue wird nicht ausgelöst - das würde man im Joblog sehen...
Meine Vermutung zielt auch eher auf ein tieferes Problem. Im Entwicklungs- & Konsolidierungssystem tritt der Fehler nicht auf. Seltsam ist, dass im Onlinemodus alles glatt läuft?
START-OF-SELECTION.
PERFORM running CHANGING lf_exit. "lauf ich schon?
IF lf_exit NE 0.
EXIT.
ENDIF.
PERFORM check_datarows CHANGING lf_exit. "sind Daten in den Tabellen? (lediglich select)
IF lf_exit NE 0.
PERFORM dequeue. "den Sperreintrag wieder raus!
EXIT.
ENDIF.
PERFORM read_and_excecute."ausführen
PERFORM dequeue. "den Sperreintrag wieder raus!
PERFORM output. "Kurzer Status zum Schluss
END-OF-SELECTION.
FORM running changing pf_exit like sy-subrc.
* 1. Laufe ich schon?
* Wenn Nein: Sperreintrag!
CALL FUNCTION 'ENQUEUE_E_TABLE'
EXPORTING
tabname = lf_repid
varkey = lf_varkey
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
* Fehler - Report läuft bereits: einfacher Write
WRITE: /,text-pru.
ENDIF.
pf_exit = sy-subrc.
* &1 &2
MESSAGE i043(zxxxi) WITH text-hm1 sy-subrc.
ENDFORM. " running
FORM dequeue .
* entsperren - Transaktion kann wieder genutzt werden...
CALL FUNCTION 'DEQUEUE_E_TABLE'
EXPORTING
* MODE_RSTABLE = 'E'
tabname = lf_repid
varkey = lf_varkey
* X_TABNAME = ' '
* X_VARKEY = ' '
* _SCOPE = '3'
* _SYNCHRON = ' '
* _COLLECT = ' '
.
* & & & &
MESSAGE i170(zxxx) WITH text-hm2 sy-datum sy-uzeit.
ENDFORM. " dequeue
Hallo,
wieso muss Tabname = Tabellenname sein? Andere Reports, welche die gleiche Technik benutzen, laufen auch. Es erscheint ein Sperreintrag in der SM12 - mehr brauch ich nicht.
Beispiel eines Reports, der läuft (SM12 Auszug)
Man Benutzer Zeitpunkt Mode Tabelle Sperrargument
092 ..... 16:21:27 E RSTABLE ZXXXX_APPLICATION
Selektierte Sperreinträge: 1
wieso muss Tabname = Tabellenname sein? Andere Reports, welche die gleiche Technik benutzen, laufen auch. Es erscheint ein Sperreintrag in der SM12 - mehr brauch ich nicht.
Beispiel eines Reports, der läuft (SM12 Auszug)
Man Benutzer Zeitpunkt Mode Tabelle Sperrargument
092 ..... 16:21:27 E RSTABLE ZXXXX_APPLICATION
Selektierte Sperreinträge: 1
Hallo,
Sperrbausteine für Tabellen benutze ich nur, wenn mein Programm auch mit der Tabelle arbeitet und sie verändert. Die Tabellenbausteine für Programmnamen zu benutzen halte ich für keine gute Idee.
Den Sperrbaustein zum Programme sperren sollte man auch nicht benutzen, denn den verwendet die Workbench, wenn jemand am Code arbeitet.
Für ein Programm, das nur einmal laufen darf, würde ich ein separates Sperrobjekt erzeugen. Dafür generiert dann das System die bekannten Bausteine und wenn man die benutzt funktioniert das immer.
Gruß
babap
Sperrbausteine für Tabellen benutze ich nur, wenn mein Programm auch mit der Tabelle arbeitet und sie verändert. Die Tabellenbausteine für Programmnamen zu benutzen halte ich für keine gute Idee.
Den Sperrbaustein zum Programme sperren sollte man auch nicht benutzen, denn den verwendet die Workbench, wenn jemand am Code arbeitet.
Für ein Programm, das nur einmal laufen darf, würde ich ein separates Sperrobjekt erzeugen. Dafür generiert dann das System die bekannten Bausteine und wenn man die benutzt funktioniert das immer.
Gruß
babap
Habe das Sperrobjekt EPROG (Sperren eines Programmes) benutzt - ohne Erfolg. Die Sperre kommt und verschwindet. Im Onlinemodus (auch ohne Debugging) läuft sie wunderbar. Nur sobald das ganze im Hintergrund läuft, verliert sie sich nach wenigen Sekunden. Die Sperre konnte mit Sy-subrc 0 (wie immer) angelegt werden... verwendeter Baustein (ENQUEUE_EPROG). Dem Baustein wird als Parameter die Reportid in einer lokalen Variablen mitgegeben...
Jemand eine Idee?
Jemand eine Idee?
Hallo,
wenn es nicht irgendeine "Systemknäcke" ist (wovon ich erstmal nicht ausgehe), dann muß man der Sache wohl im Programm auf den Grund gehen.
Wenn alles nichts hilft mußt Du im Batch debuggen.
(If sy-batch = 'X', dann Endlosschleife, und sich aufschalten)
Oder vorher doch noch einen "Papier- und Bleistifttest" durchführen ...
Gruß
babap
P.S. Du kannst aber auch nicht die Finger weglassen von fremden "Sperrobjekten" oder
???
wenn es nicht irgendeine "Systemknäcke" ist (wovon ich erstmal nicht ausgehe), dann muß man der Sache wohl im Programm auf den Grund gehen.
Wenn alles nichts hilft mußt Du im Batch debuggen.
(If sy-batch = 'X', dann Endlosschleife, und sich aufschalten)
Oder vorher doch noch einen "Papier- und Bleistifttest" durchführen ...
Gruß
babap
P.S. Du kannst aber auch nicht die Finger weglassen von fremden "Sperrobjekten" oder
???
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Ich würde mich sehr wundern, wenn die Antwort nicht schon seit einer Woche feststeht (s. meinen vorherigen Beitrag.)babap hat geschrieben:wenn es nicht irgendeine "Systemknäcke" ist (wovon ich erstmal nicht ausgehe), dann muß man der Sache wohl im Programm auf den Grund gehen.
Vergleichbare Themen
2
Antw.
Antw.
2373
Views
Views
ENQUEUE beim VIEW_MAINTENANCE_CALL
von michael.schoeffer » 26.10.2006 12:51 • Verfasst in ABAP® für Anfänger
von michael.schoeffer » 26.10.2006 12:51 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
265
Views
Views
17
Antw.
Antw.
11240
Views
Views
1
Antw.
Antw.
1272
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.