[Gelöst] Nach anlegen einer Nummernserie, Transaktionsfehler

Ich habe einen kuriosen Fehler.. der höchstwarscheinlich mit unserer Individualanpassung zu tun hat. Aber vielleicht hat einer von euch eine Idee.

Wir hatten, nachdem wir von der Nativen DB auf eine SQL DB gewechselt sind, immer diesen netten Fehler "Ein anderer Anwender hat...". Nach einigem rummprobieren habe ich die Codezeilen die dafür verantworlich zu sein schienen erfolgreich auskommentiert. Bisher funktionierte auch alles wunderbar.

Nun passiert folgendes. Wir haben eine Contact Card (individual anpassung aber mehr oder weniger nur eine Kopie von der original Contact Card) dort gibt es das Feld Vermittlernummer. Dies ist standardmäßig leer. Es kann aber durchaus sein das ein Datensatz ein Vermittler wird. Dann führen wir eine Funktion aus die eine Nummer aus der hinterlegten Nummernserie in das Feld einfügt. Soweit kein Problem. Möchte ich diesen Datensatz aber nun ändern, bekomme ich jedesmal diesen "Ein anderer Anwender hat..." Fehler. Ohne vergebene Vermittlernummer konnte ich alles einwandfrei ändern.
Ich habe auch leider keinen Code gefunden der irgendwie sagt "Wenn Vermittlernummer vergeben dann kann nix mehr geändert werden..." oder so ähnlich. Hat von euch vielleicht jemand ne Idee?

Der Debugger hat mich leider auch nicht weiter gebracht.

Zuletzt geändert von Heike Bennerscheid am 15. Januar 2008 10:34, insgesamt 1-mal geändert.

Möchte ich diesen Datensatz aber nun ändern, bekomme ich jedesmal diesen "Ein anderer Anwender hat..." Fehler

Probiere es mit einem erneuten GET. Offenbar hat der Transaktionszeitstempel des Datensatzes einen anderen Wert als der NAV-Client angenommen hat.

Möchte ich diesen Datensatz aber nun ändern, bekomme ich jedesmal diesen "Ein anderer Anwender hat..." Fehler

Probiere es mit einem erneuten GET. Offenbar hat der Transaktionszeitstempel des Datensatzes einen anderen Wert als der NAV-Client angenommen hat.

Versteh ich leider nicht so ganz.

Zudem sollte der Fehler dann nicht auch auftauchen wenn der Datensatz keine Vermittlernummer hat?

Die Versionskontrolle in NAV auf SQL funktioniert ähnlich wie das "Erweiterte Zeitstempelverfahren". Dazu gibt es in jeder SQL-Tabelle ein Feld timestamp. Navision führt die Zugriffe i.d.R. READUNCOMMITTED aus, d.h. sog. Dirty Reads sind möglich. Dieses timestamp-Feld hat einen Wert beim Lesen und beim Schreiben wird der Lese-timestamp mit dem Schreib-timestamp-Wert vergliechen. Wenn beide abweichen, weil ein andere Client ggf. eun Pseudoupdate vorgenommen hat, gibt es einen "Ein anderer Anwender hat..."-Fehler.

Ein erneutes GET wird in diesem Fall helfen.

Wo trage ich dieses GET denn dann ein?

Ich würde es nach dem Ziehen aus der Nummernserie vermuten.

Das ziehen der Vermittlernummer aus der Nummernserie passiert ja nur einmalig.
Deswegen wüsst ich jetzt nicht was dies ändern würde. Oder hab ich jetzt nen Denkfehler?

Das Problem hat sich gelöst. Es war meine eigene Individualanpassung. Dort wurde ein Report aufgerufen mit einem Modify. Diese Anpassung wird aber zum Glück nicht mehr benötigt und konnte auskommentiert werden.

Danke für deine Mühen MrBurns.