Buchen und Sperrung von Verkaufszeile

Hallo,

bei einem unserer Kunden ist der Classic-Client im Einsatz.
Es kommt beim Buchen der Verkaufsaufträge bei den Mitarbeitern immer wieder die Meldung:
'Die Verkaufszeile-Tabelle kann nicht geändert werden, weil sie von einem anderen Benutzer gesperrt ist'

Der Kunde hat den Microsoft SQL-Server 2008 im Einsatz.
Das Problem exitierte auch schon bei Dynamics NAV 5.1 und SQL Server 2005.

Bei keinem anderem Kunden tritt dies auf. Der Code ist identisch mit dem der anderen Kunden.
Auch bei Kunden mit mehr Mitarbeitern, die Verkaufsbuchungen durchführen tritt das Problem nicht auf.

Ursache scheint das LOCKTABLE in der Sales-Post Codunit 80 zu sein.

Kennt jemand das Problem und hat einen Lösungsvorschlag?

grüße
Jürgen Bratzke

Schau mal die Analyseansichten an, ob die "Automated Update on Posting" an sind.
Auch die automatische Kostenbuchung in der Einrichtung anschauen, ob der Haken gesetzt ist.
Das verursacht Mehraufwand beim Buchen.

Schau dir mal KB978100 an.

Gilt das auch für R2?
Müsste sowas nicht generell mitausgeliefert werden bei Neuinstallationen, um diese Tests mit dem Einführungsprojekt auszuführen?

Gilt das auch für R2?

Galt das meinem Beitrag?
Wenn ja: scheinbar nicht.

Der Isolation Level SERIALIZABLE ist für Transaktionen wie sie in einem ERP System erforderlich sind aus einer Konsistenzsicht auf jeden Fall zu bevorzugen, da wie im Beispiel im Artikel gezeigt wird, hier u.a. keine Phantom Reads auftreten können.

However, Geschwindigkeit ist Hexerei und ist nur durch noch mehr Geschwindigkeit zu übertreffen. Im allgemeinen werden Phantom Reads nicht zu inkonsistenten Daten sondern hauptsächlich zu einem gefühlt weniger beschäftigten/gesperrten System führen.

Das beschriebene Flag ist auch für NAV 2009 R2 gültig, ich gebe aber zu, dass ich den Auslieferzustand nicht und schon gar nicht die Herkunft eurer Datenbank kenne :)

Dementsprechend schau mal in die Tabelle $ndo$dbproperty und prüfe das Flag.

Der Isolation Level SERIALIZABLE ist für Transaktionen wie sie in einem ERP System erforderlich sind aus einer Konsistenzsicht auf jeden Fall zu bevorzugen, da wie im Beispiel im Artikel gezeigt wird, hier u.a. keine Phantom Reads auftreten können.

However, Geschwindigkeit ist Hexerei und ist nur durch noch mehr Geschwindigkeit zu übertreffen. Im allgemeinen werden Phantom Reads nicht zu inkonsistenten Daten sondern hauptsächlich zu einem gefühlt weniger beschäftigten/gesperrten System führen.

Das beschriebene Flag ist auch für NAV 2009 R2 gültig, ich gebe aber zu, dass ich den Auslieferzustand nicht und schon gar nicht die Herkunft eurer Datenbank kenne :)

Dementsprechend schau mal in die Tabelle $ndo$dbproperty und prüfe das Flag.

Hallo Carsten,
Hallo zusammen,

auch wenn der Beitrag schon älter ist. Bezüglich den Isolation Levels gibts da einiges was sich hier meiner Meinung nach widerspricht. Laut dem Überblick der verschiedenen Isolation Levels hier:


http://msdn.microsoft.com/en-us/library/ms189122%28SQL.105%29.aspx

sollte es ja so sein das bezüglich Sperrproblematik ja "Read uncommitted" das günstigste sein müßte. Laut Jörg Stryk ist das auch der Standard in Navision. Hat er z.B. hier erklärt:


http://dynamicsuser.net/blogs/stryk/archive/2008/11/03/blocks-amp-deadlocks-in-nav-with-sql-server.aspx

Wenn das aber so ist, welchen Sinn macht es denn dann hier den Isolation Level auf "Repeatable Read" umzustellen, wie z.B. hier beschrieben:


http://blogs.msdn.com/b/nav/archive/2011/05/12/microsoft-dynamics-nav-changes-by-version.aspx

Das als Isolation Level "SERIALIZABLE" am schlechtesten ist und bei LOCKTABLE oder FINDSET(TRUE) automatisch umgestellt wird habe ich soweit verstanden und macht auch Sinn, aber vielleicht kann mir ja jemand obige Punkte erklären.

Also inzwischen kann man diesen "Tweak" - Umstellung auf REPEATABLE READ Isolation - durchaus empfehlen!

Der Hauptunterschied ist, dass beim "alten" SERIALIZABLE sog. "Range Locks" aufgebaut werden, die mit Hauptursache für Blocks sind. Mit REPEATABLE READ werden die Daten immer noch "clean" gelesen, aber es werden eben keine "Range Locks" erzeugt! Und damit kann man das Blockade-Risiko drastisch reduzieren.

Weil aber jetzt eben soz. der "Range" offen ist, könnten in diesen - theoretisch - DS eingfügt werden obwohl die Transaktion noch offen ist; das nennt man dann "Phantom Reads". Aufgrund diese potentiellen Risikos hat mat RR Islation lange diskutiert, mittlerweile kann man aber sagen: Phantom Reads ist eher ein akademisches Problem als ein reales.

Ich selbst bin noch nie auf ein "Phantom Read" Problem gestossen, auch nicht diverse Partner oder auch MS Mitarbeiter. Inzwischen ist RR Isolation eben auch Standard geworden (in NAV 2013).

Also inzwischen kann man diesen "Tweak" - Umstellung auf REPEATABLE READ Isolation - durchaus empfehlen!

Hallo Jörg,

danke für deine Antwort. Eine Nachfrage hierzu hätte ich aber doch nochmal. Heißt das dann eigentlich das bei Anwendung dieses Tweaks bzw. in NAV2013 vom Grundsatz her der höchste Isolation Level dann REPEATABLE READ ist anstatt SERIALIZABLE? Auch im Zusammenhang von LOCKTABLE und FINDSET(TRUE)-Anweisungen?

Heißt das dann eigentlich das bei Anwendung dieses Tweaks bzw. in NAV2013 vom Grundsatz her der höchste Isolation Level dann REPEATABLE READ ist anstatt SERIALIZABLE? Auch im Zusammenhang von LOCKTABLE und FINDSET(TRUE)-Anweisungen?

Also in NAV 7 scheinen die "Uhren eh anders zu ticken" ... neben READUNCOMMITTED und REPEATABLE READ setzt NAV 7 auch explizite XLOCK etc. ... so ganz blicke ich da auch noch nicht durch ...