[Gelöst] Fehler beim Ausgleich von Deb.-posten unter 4.03SQL

25. Juli 2007 10:29

Hallo zusammen.

Leider habe ich zu meinem Problem nichts adäquates in diesem Forum gefunden.

Zum Sachverhalt:
Es wurde die Version 4.03 installiert, als Datenbank verwenden wir den SQL-Server.
Die Applikation ist die Version 3.70, wir haben also nur ein technisches Update vorgenommen.
Beim Ausgleich von Debitorenposten erhalten wir folgende Fehlermeldung:
"Ein anderer Anwender hat den Datensatz für diese Debitorenposten geändert, nachdem er angezeigt wurde. Geben Sie Ihre Änderungen noch einmal in das aktualisierte Fenster ein oder nehmen Sie die unterbrochene Aktivität wieder auf."

Die Lfd-Nr. des Debitorenpostens, der hierbei "angemeckert" wird, ist derjenige, auf dem sich zum Zeitpunkt des Buchens der Datensatzzeiger befindet.

Es ist ja richtig, dass die Debitorenposten durch die Codeunit 12 verändert werden. Es ist auch richtig, dass in der Codeunit 12 noch ein "Modify" auf den Debitorenposten stattfindet, schliesslich verändern sich die Restbeträge usw.
Nur die Form 232 hat damit ein Problem.

Komisch ist es auch deshalb, weil mit den selben Daten das Buchen unter der C/Side-Datenbank wie gewohnt einwandfrei funktioniert.
Es kann also m. E. nur am SQL-Server liegen.

Hat jemand (ähnliche) Erfahrungen gemacht?
Gibt es Lösungsvorschläge?
Habe nicht wirklich Muße, ein Update von 3.70 auf 4.03 durchzuführen, bei ca. 600 individuell angepassten Objekten :cry:

Grüße
Rainer
Zuletzt geändert von rainermatuschek am 25. Juli 2007 17:14, insgesamt 2-mal geändert.

25. Juli 2007 10:39

Probier doch mal, ob ein passend positioniertes CurrForm.UPDATE auf der Form 232 (beim entsprechenden Button-Click nach Aufruf der Codeunit) das Problem behebt.

25. Juli 2007 10:50

Leider nicht, auch schon probiert.
Problem ist das Modify in der Codeunit 12 (Funktion CustPostApplyCustLedgEntry).

Bei diesem Modify kommt die Fehlermeldung.
Laut meinen Recherchen wird diese Funktion nur einmal aufgerufen, unabhängig davon, wie viele Posten für einen Ausgleich markiert wurden.
In dieser Funktion soll eigentlich der Debitorenposten aktualisiert werden, auf dem der Datensatzzeiger in der Form 232 steht.

D. h., es müsste die Funktion gefunden werden, bei der die übrigen, ebenfalls für einen Ausgleich markierten, Posten aktualisiert werden.
Vielleicht kann ich da eingreifen, so dass der Modify in der zuvor genannten Funktion ggf. deaktiviert werden kann.

25. Juli 2007 11:32

Wir haben diesen Fehler auch schon öfters gehabt (Verwenden als DB 4.0 SP1 auf SQL 2k)

öfters hängt es mit einem Filter zusammen,wobei ich mir immer noch nicht im klaren bin, warum eigentlich.

Aber interessieren würde mich die Lösung auch, da bei uns öfters im Bereich Produktion beim ändern des Status die Meldung mit "Ein anderer Benutzer..." Aber gehabt haben wir das Ganze auch schon öfters im Verkauf. (komischerweise haben sich bis jetzt aber nur Leute gemeldet, die mit Filtern arbeiten *grübel*)

25. Juli 2007 12:08

Die Versionskontrolle in 4.0 SQL ist strenger als in den älteren Versionen, daher kommen diese Fehlermeldungen. Der Code muss überarbeitet werden. Dieses ist in dem Upgrade Toolkit Document auf Seite 85/86 beschrieben worden.
Zuletzt geändert von Kowa am 25. Juli 2007 12:11, insgesamt 1-mal geändert.

25. Juli 2007 12:11

Wenn es mit den Filtern zusammenhängt, ist wahrscheinlich ein Filter auf ein Feld gesetzt, was in der Funktion geändert werden soll. Durch die Änderung fällt der Datensatz dann aus dem Filter und steht nicht mehr zur Verfügung. Navision findet dann den nächsten oder keinen Datensatz mehr und glaubt, jemand anderes hätte geändert.

25. Juli 2007 12:17

Kowa hat geschrieben:Die Versionskontrolle in 4.0 SQL ist strenger als in den älteren Versionen, daher kommen diese Fehlermeldungen. Der Code muss überarbeitet werden. Dieses ist in dem Upgrade Toolkit Document auf Seite 85/86 beschrieben worden.


Wo kann man denn dieses Dokument herbekommen? (Download?)

25. Juli 2007 12:36

@Kowa
Danke, habe das Dokument gefunden.
Problem ist auch schon gelöst.
In der Codeunit 12 habe ich vor dem CustLedgEntry.modify ein custledgentry.get gesetzt.

Jetzt müssen wir nur noch die ausgeglichen Posten auf Plausibilität prüfen.

Sind diese Posten tatsächlich OK, setzten ich den Beitrag auf "Gelöst".

Grüße
Rainer