Probleme beim gleichzeitigen Tabellenzugriff

Hallo!

Ich denke jeder kennt das Problem, wenn mehre Benutzer gleichzeitig auf eine Tabelle zugreifen wollen. Oder wenn man debuggt bzw. bei einem Benutzer eine ERROR-Message offen stehen bleibt oder ein umfangreicherer Report läuft.
Fehlermeldung siehe Anhang.

Kann man die Programmierung so anpassen, dass das nicht mehr vorkommt?!

Gruss

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Native oder SQL?

Wenn Native, dann ist die ganze Tabelle, die ein Benutzer A gerade im Zugriff hat, komplett gesperrt. Dagegen kann man nichts machen.

Die Programmierung kann nur dahin gehend "optimiert" werden, dass Benutzer B automatisch wartet, bis die Tabelle wieder frei ist, anstatt die Fehlermeldung zu erhalten.
Dies müsste dann aber an vielen Stellen umprogrammiert wird (hat damit hier jemand schon Erfahrung?).

SQL ist da schon optimierter: Es wird nach Möglichkeit nur der einzelne Datensatz (+ einen davor und danach) gesperrt, was die Wahrscheinlichkeit dieser Fehlermeldungen deutlich reduziert. Aber auch hier könnte man das Verhalten bei Sperren umprogrammieren.

Hallo,
vielen Dank für deine Antwort.
Wir setzen einen SQL-Server ein.

Hm ok, also mit LOCKTABLE die Programmierung optimieren.
Könnte dafür auch der OnModify-Trigger einer Tabelle genügen?
Bzw. die AnwendungVerwaltung? (OnGlobalModify für Changelog)

Gruss

Hm ok, also mit LOCKTABLE die Programmierung optimieren.
Könnte dafür auch der OnModify-Trigger einer Tabelle genügen?
Bzw. die AnwendungVerwaltung? (OnGlobalModify für Changelog)

Bei der Änderung eines Datensatzes wird dieser automatisch gesperrt. Und darauf hast du keinen Einfluss. Das was ich meinte, sind vorhandene LOCKTABLEs. Aber damit habe ich ehrlich gesagt auch keine Erfahrung.

Aber ist das wirklich notwendig?

Ich habe erst jetzt gelesen, dass es beim Debuggen auftritt. Das ist bekannt:
Niemals (tagsüber) im Produktivsystem debuggen - das blockiert immer alle beobachteten Tabellen und darauf hast du auch keinen Einfluss!
Wenn du also debuggen willst, dann verwende ein Testsystem oder informiere die Benutzer, dass sie mal 5 Minuten Navision-Pause machen.

...bzw. bei einem Benutzer eine ERROR-Message offen stehen bleibt...

Ein ERROR beendet immer die Datenbanktransaktion und löst alle Sperren. Vermutlich sind das CONFIRM oder MESSAGE Befehle. Diese sollten in Buchungsvorgängen nicht verwendet werden, da sie bestätigt werden müssen. Wenn unbedingt erforderlich, kann ganz am Ende ein MESSAGE stehen, unmittelbar vorher dann aber ein COMMIT setzen.

MESSAGE ist meines Wissens nach kein Problem. Es erwartet keine Bestätigung und erscheint ohnehin erst ganz am Ende der Transaktion - ganz gleich, wo im Quelltext es vorher platziert worden war.

MESSAGE ist meines Wissens nach kein Problem. Es erwartet keine Bestätigung und erscheint ohnehin erst ganz am Ende der Transaktion - ganz gleich, wo im Quelltext es vorher platziert worden war.

Eben deshalb macht es ja keinen Sinn, es mitten in der Transaktion einzubauen, weil es ohnehin erst am Ende erscheint, und es sich auch nicht selbsttätig wie ein Dialogfenster wieder schließt.

Die Beschreibung mit dem Error stimmt schon (leider).
Denn bei 4.03 HF 6 und auch bei der 5.0-er (HF1) hatte sich ein Bug eingeschliechen, welcher eine Transaktion erst wieder rückgängig gemacht hat, wenn der Benutzer die Fehlermeldung wegklickt.
siehe Post auf mibuso

http://www.mibuso.com/forum/viewtopic.php?t=22706

Bei der Änderung eines Datensatzes wird dieser automatisch gesperrt. Und darauf hast du keinen Einfluss. Das was ich meinte, sind vorhandene LOCKTABLEs. Aber damit habe ich ehrlich gesagt auch keine Erfahrung.

Aber ist das wirklich notwendig?

Ja. Für die Inventur lassen wir einen Report laufen, der auf mehrere Tabellen zugreift. Dauer ca. 15-20 Min. Dadurch sperren sich Tabellen.

Hm, LOCKTABLE (Record.LOCKTABLE([Wait] [, VersionCheck])) hat eine Warte-Funktion eingebaut. Dann werd ich das mal ausprobieren.

Gruss

rein theoretisch bringt das nix, weil für den Anwender die Applikation nicht zugänglich ist, d.h. sie "hängt".

Gruss