Sperreinträge Transaktionsübergreifend behandeln

Sperreinträge Transaktionsübergreifend behandeln

Hallo,

ich habe ein Problem beim Sperren/ Entsperren:

In der Transaktion Z_EINS wird ein Objekt mit dem SAP-Standard-Sperrbaustein "ENQUEUE_XYZ" gesperrt.

Dann wird zur weiteren Bearbeitung in die Transaktion Z_ZWEI gewechselt. Hier kann nun das zu bearbeitende Objekt gewechstelt werden. Dazu muss dann das alte Objekt entsperrt und das neu gesperrt werden. Nur leider funktioniert das Entsperren des Objektes nicht. Ich nehme an, dass die Transaktion Z_ZWEI keine "Berechtigung" hat, das Objekt zu entsperren, da es in der Transaktion Z_EINS gesperrt wurde.

Der FuBa DEQUEUE_ALL scheitert an dem selben Problem.

Wenn ich die Programmierung in der Art:
Transaktion Z_EINS:
Objekt 123 sperren
Bearbeitung
Objekt 123 entsperren
Call Transaktion Z_ZWEI
Objekt 123 sperren
...

Dann habe ich die Befürchtung, dass in der Zeit zwischen Entsperren und Sperren in der neuen Transaktion ein anderer User dazwischen funken kann.

Hat jemand ein Idee?

fragt Enno.

PS: Sorry, ist in die falsche Kategorie gerutscht! Hat natürlich nix mit OO-Programmierung zu tun...

Hi LoLo,

ein einfacher CALL TRANSACTION 'Z_ZWEI'.
Die Sperren werden aber nicht abgebaut; es erfolgt kein Commit Work!

Das Objekt ist übrigens auch nicht mehrfach gesperrt.
ich habe schon ein versucht.

Gruß, Enno.

Hi Enno,

setzt die 2. Transaktion auch eine Sperre ab, so dass Du evtl. kummulative Sperren sitzen hast? Normalerweise sollte über ein Aufruf von DEQUEUE die Sperre entfernt werden können. Wie wird denn die erste Sperre gesetzt? _SCOPE = 3?
Hast Du mal über die SM12 nachgeschaut? Eigentlich gehört die Sperre ja dem Dialogbenutzer insofern muss es möglich sein, in eine andere Transaktion zu springen und dort die Sperre über einen Dequeue wieder abzubauen.
Probier doch mal über die SE37 den DEQUEUE auszuführen, wenn die Sperre in der SM12 sitzt. Dann kannst Du wenigsten prüfen, ob die Sperrargumente die richtigen sind um die Sperre abzubauen.

LoLo

Hallo,

laut SAP ist es tatsächlich so, dass die Sperren nicht transaktionsübergreifend aufgehoben werden können.
Jedenfalls nicht im Normalfall. Es gibt da wohl einen Trick, der bei RFC's verwendet wird. Aber den wollen sie mir noch nicht verraten....
Enno

babap hat geschrieben:Hallo,

mir ist der Anwendungsfall noch nicht ganz klar.

Erst wird ein Objekt ausgewählt und gesperrt,

Dann wird mit Übergabe des Objektes eine "Pflegetransaktion" aufgerufen.

Die kann dann pflegen oder das Objekt wechseln ...

Da hilft nur, kurz vorher entsperren und danach wieder sperren, mit nicht ganz 100%-igem Erfolg.

eben... das ist mir zu unsicher.

Man kann natürlich die Sperre erst in der zweiten Transaktion setzen, wenn das mit "gesperrt!" zurückkommt, sitzt da noch jemand drauf.

Oder wie wäre es, den Objektwechsel nur in der aufrufenden Transaktion vornehmen zu lassen.

Das wäre noch eine gute Idee!

Die Pflegetransaktion beendet sich mit einer Meldung S... und fordert bei der aufrufenden den Wechsel des Objektes (mit Entsperren Sperren) und wird dann wieder aufgerufen. (Ist aber wirklich durch die Brust ins Auge).

Oder Du sparst Dir ganz die erste Transaktion und packst das alles in eine.

Das ist eben doch recht aufwändig, weil es sich insgesamt um drei recht große Transaktionen handelt. Das wäre so ähnlich, als hätte ich Probleme beim Sperren eines Vertriebsbeleges wenn ich über den Belegfluß navigiere und du mir rätst, die VA02, VL02n, VF02 etc in eine Transaktion zu packen.

mfg.
babap

Vielen Dank für deine Vor- und Ratschläge!

Gruß, Enno Wulff.

Re: Hole die

Hallo Daniel,


mal kurz eine Frage zum Versorgen der 2. Transaktion mit den notwendigen Owner-Angaben: Wann und wo wird der FB 'SET_ENQUEUE_OWNER' denn aufgerufen? Ist da eine Modifikation der 2. Transaktion notwendig?


Vielen Dank im voraus!


Ciao, Michael