ich habe da ein Problem.
In einem Funktionsbaustein wird etwas in einer Datenbanktabelle geändert.
Ein COMMIT WORK AND WAIT schließt das ganze dann ab.
Die Änderungen sind zu diesem Zeitpunkt dann auch auf der Datenbank abgespeichert.
Aber nach diesem Funktionsbaustein wird noch ein anderer aufgerufen, der auch nur Datensätze an diese Tabelle anhängt.
Danach kommt wieder ein COMMIT WORK AND WAIT.
Die neuen Datensätze sind gespeichert, aber die Änderungen von dem ersten Funktionsbaustein sind wieder zurückgenommen. ????
Im Verbucher stand nichts mehr.
Hier noch ein Beispiel:
Tabelle: NLEI
Leistung | Beginndatum | Endedatum
Leist1 | 08.01.2006 | 31.12.9999
Das seltsame ist. Dieser Fehler tritt nur auf einer Maschine auf.
Auf einer anderen mit dem gleichen Release und Patchstand tritt dieser Fehler nicht auf.
Hat da jemand eine Idee? Ich stehe da wirklich auf dem Schlauch.
Wenn du mit Verbuchungsbausteinen arbeitest (geht nicht eindeutig aus deiner BEschreibung hervor...), dann setz mal zu Beginn des Programms SET UPDATE TASK LOCAL.
Wahrscheinlich ist die eine Maschine schneller, als die andere oder hat einen besseren Draht zur Datenbank...
Aber wie kann es daran liegen?
Ich habe mir während des Debuggens die ganze Zeit in SE16N die Tabelle NLEI angesehen. Nach dem COMMIT WORK AND WAIT im ersten Funktionsbaustein waren die Werte in der Tabelle richtig abgespeichert.
Nach dem COMMIT WORK AND WAIT des zweiten Funktionsbausteins waren die Werte dann wieder wie vor dem ersten Funktionsbaustein.
Das spricht doch dafür, dass die Verbuchung schon abgeschlossen war.
gemäß Deiner Beschreibung kommt es zu folgendem Effekt:
VB1 schreibt mehrere Zeilen in Deine Tabelle
VB2 schreibt auch mehrere, zum Teil aber gleiche, Zeilen in Deine Tabelle
Für beide VB wurde der bisherige Datenbestand zu Beginn der Transaktion in ihren jeweiligen Puffer gelesen. Die Daten für VB1 werden nun geändert, aber VB2 bekommt davon nichts mit und hat deshalb immer noch den alten Stand, den er auch wieder auf die DB zurückschreibt...
Du musst also einen Weg finden, dass VB2 entweder die Finger von den bereits geänderten Sätzen läßt, oder davon Kenntnis erhält...
Gruß
Ereglam
May the Force be with your code || .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Der 2. Funktionsbaustein ändert doch gar nichts an den Datensätzen, die der 1. Funktionsbaustein ändert oder anlegt.
Der COMMIT WORK AND WAIT macht ja diese Probleme.
Im ersten Funktionsbaustein ändere ich Datensätze und füge welche hinzu.
Dies geschieht mittels eines BAPIs.
Im zweiten Funktionsbaustein werden nur Datensätze hinzugefügt.
Dies geschieht ebenfalls mittels des selben BAPIs.
Nach jedem BAPI-Aufruf commt ein COMMTI WORK AND WAIT, bzw ein Aufruf des BAPIs "BAPI_TRANSACTION_COMMIT", der ja bekanntlich das selbe macht. (Oder ruft dieser BAPI andere Methoden nach dem COMMIT auf?)
Das kommt auf die BAPI's an. Blöderweise sind das auch keine BAPI_REFRESH_IRGENDWAS-Bausteine, sondern halt andere.
Beim Anlegen/ Ändern von Chargen z.B. heisst der VB_INIT.
Hast du im OSS zu "deinem" BAPI schon mal gesucht?
Gruß, Enno
wenn du irgendwann mal mitteilst welcher BAPI denn überhaupt verwendet wird und am Besten noch das Coding mit dem du die BAPIs füllst könnte dir evtl. weitergeholfen werden.
Weiterhin wäre es interessant welches die aktuellen Inhalte der Übergabeparameter beim Aufruf der BAPIs sind.
Den BAPI kann ich dir nennen, jedoch nicht die Inhalte der Parameter.
Diese fallen unter den Datenschutz.
Es handelt sich um den Funktionsbaustein 'ISH_CASESERVICE_MODIFYMULTIPLE', der im Prinzip genauso arbeitet, wie die BAPIs 'BAPI_CASESERVICE_CANCELMULT', 'BAPI_CASESERVICE_CHANGEMULT' und 'BAPI_CASESERVICE_CREATEMULT'.
Dieser Funktionsbaustein hat den Vorteil gegenüber den BAPIs, dass er alle 3 Aktionen (Anlegen, Ändern und Stornieren) unterstützt.
Davon ganz abgesehen wird dieser Funktionsbaustein auch von den BAPIs aufgerufen.