[GELÖST]Sperrproblematik unter Nativen Datenbank

Hey Zusammen,

mittlerweile gehen mir die Ideen aus (außer auf eine SQL Datenbank umzusteigen).

Ich verarbeite vollautomatisch despatch advice.
Häufig kommt es vor, dass nicht angeliefert werden soll, was bestellt wurde.

Oder aber es kommt in unterschiedlichen Teilmengen, bsp:

Bestellt 1000 Stk
Angeliefert werden 600 Stk von Lieferant A und 400 Stk von Lieferant B.

Für solche und noch weitere Fälle (bestellt 1000 Stk., geliefert werden 800 Stk.) passe ich unsere Wareneingangs-Tabelle an.

Nun kommt es doch extrem häufig vor, dass diese scheinbar gesperrt wird (weil ein WE-Mitarbeiter an irgendeinem Datensatz arbeitet) und meine Schnittstelle deswegen die Anpassungen an dem WE nicht vornimmt, überspringt und zum nächsten über geht.

Um dem irgendwie entgegenzuwirken, habe ich beispielsweise im OnPreDataItem vom Verarbeitungs-Report folgendes eingebaut:

g_recWEZeile.RESET;
g_recWEZeile.LOCKTABLE;

Trotzdem wird mein Job häufiger als mir lieb ist von einem WE-Mitarbeiter gesperrt.


Hat jemand eine Idee oder einen Tipp wie man damit am besten umgeht?

Zuletzt geändert von MSNAVLerner am 13. Juni 2017 15:42, insgesamt 1-mal geändert.

Wenn ich das richtig im Kopf habe, wird das LOCKTABLE je nach Einstellung u.U. erst zu einem späteren Zeitpunkt wirklich ausgeführt. Daher bringt es an der Stelle vielleicht gar nichts.

Ist es denn zwingend notwendig den Wareneingang im laufenden Betrieb einzufügen oder könnte man nicht auch sammeln und bspw. am Abend alles auf einmal übernehmen?

Benutzt der automatische Prozess den gleichen Buch.-Blatt Namen wie die MA? Könnte man das ggf. umstellen?

Ja da führt kein Weg dran vorbei, dass ich den Wareneingang umgehend nach Erhalt der DesAdv direkt anpasse.

Meine Schnittstelle geht bei Abweichungen von Bestellung und Wareneingang in die jeweilige Wareneingangszeilen und löscht dort Zeilen, legt neue an oder modifiziert bestehende Zeilen.

Hast du auch folgendes versucht:

Code:

g_recWEZeile.LOCKTABLE(TRUE);

Quelle

Wenn ich das richtig im Kopf habe, wird das LOCKTABLE je nach Einstellung u.U. erst zu einem späteren Zeitpunkt wirklich ausgeführt.

Das trifft nur beim SQL-Server zu.
Locking in Microsoft SQL Server
How to detect locking order for a NAV process
Beim Native Server hat es dagegen sofort Auswirkung, siehe Diagramm hier:
Table Locking

Hallo,

Klingt nach einer Zwischentabelle, die Du für die Änderungen erstmal verwendest. Wenn die Wareneingangszeilen nicht berührt werden kannst Du dann auch problemlos committen. Und dann mittels Job Queue (oder wenn man es sich traut, auf dem OnInsert/OnModify Trigger des Wareneingangsforms) die Verarbeitung in Bezug auf die Wareneingangszeilen anschieben. Wobei ich mich frage, wenn die Lieferung dann ggf. von einem anderen Lieferanten kommt, ist das schon eine Aktion - gesonderte Teilbestellung?

LG Jens

Ich schreibe direkt in eine eigens entwickelte Wareneingastabelle (Kopf- und Zeile).

Das mit den unterschiedlichen Lieferanten liegt daran, dass wir bei großen Zwischenhändler bestellen.
Da bestellst 1000 Stk. und der schickt dir dann beispielsweise 500 Stk. mit Lot-Nr. 1234 von Lieferant A und 500 Stk. mit Lot-Nr. 84730 von Lieferant B.

Aus diesem Grund splitte ich sowohl in der Bestellung als auch im Wareneingangsdialog die Zeile.

Das Interessante ist jedoch, dass es beim Bestellzeilen-Splitting nie zu Problemen kommt.
Ich versuche jetzt zu ermitteln, ob der Fehler ggfs. auch noch wo anders liegt und nicht "nur" an Sperrung der Tabelle.

LG

Hast du auch folgendes versucht:

Code:

g_recWEZeile.LOCKTABLE(TRUE);

LOCKTABLE ohne Parameter verwendet bereits die Vorgabewerte LOCKTABLE(TRUE,FALSE). Beim SQL-Server ist das auch die einzige zulässige Einstellung, die dort dann nicht zu Laufzeitfehlern führt.

Du kannst die Wahrscheinlichkeit das es zu einem Lock kommt verringern, wenn du alle Änderungen in einer temporären Tabelle machst und ganz am Ende in die echte Tabelle schreibst. (Für den Fall, dass viele WE Zeilen in bestimmten Intervallen verarbeitet werden.)

An welcher Stelle setzt denn deine Programmierung an? Vielleicht macht es Sinn, die zu bearbeitenden WE Zeilen vorm User zu verstecken. Am besten so, das der User diese gar nicht erst zu Gesicht bekommt, bevor nicht deine Programmierung drüber gegangen ist. Das kann ja ein Booleanfeld sein, welches du nach deiner Bearbeitung änderst.

Meine Anwender arbeiten nicht an den WE´s, die von meiner Schnittstelle überarbeitet werden.
Sie arbeiten an anderen WE´s und dadurch besteht scheinbar die Gefahr, dass meine Schnittstelle gesperrt wird.

Vermutlich bleibt nichts anderes übrig, als über Timing.
Die Uhrzeiten für die Schnittstelle sind definiert.

Das trifft nur beim SQL-Server zu.

Ah... gepflegt überlesen.

(außer auf eine SQL Datenbank umzusteigen)