Sperrtabelle greift nicht

[Milvus]

@WurliWurm:

Was hälst Du von meinem Ansatz mit ADO/RecordsAffected, das ich dann auswerte?

Hintergrund: Wenn eine Sperre gesetzt wird, soll die zu bearbeitende Zeile aufgerufen werden. Das wird dann mit WHERE eingeschränkt, letztendlich (darauf kommts mir gerade an) darf kein Lock drin stehen. Ansonsten wird keine Zeile zurück geliefert und die Long-Variable ist 0, d.h. die Zeile ist gesperrt (es ist kein Fehler aufgetreden und der Lock wurde nicht geändert)!
Wenn es irgendwo anders knallt (also ein Fehler), dann haut die Transaktion nicht hin, was ich ja ebenfalls abfagen kann.

[Wurliwurm]

Dass das rein von der Auflösung her mit nur einer Tabelle geht, ist mir bewusst. Ich normiere leidenschaftlich gerne.

Mit Normalisierung hat das streng genommen nichts zu tun, Normalisierung bezieht sich immer nur auf eine einzelne Relation. Nenne es besser "gutes Design".

Ich sag mal so: Wenn ich es gezielt hinbekomme, dass die Datenbank immer nur die Zeile sperrt, die versucht wird zu bearbeiten (wie mache ich das oder ist das Standard?), dann setze ich eine normierte Sperrtabelle auf, in der jeder Bereich seine eigene Zeile hat. Damit wären die Spatzen gefangen.

Wie breit gesperrt wird, hängt von der Datenbank ab. Oracle sperrt bekanntlich sehr granular, enger als der MS SQL-Server. Allgemein kann man sagen, daß die DBMS immer ganze Seiten sperren, die über mehrere Datensätze hinausgehen.

Ob es etwas bringt, hier zu breites Sperren zu umgehen, indem man auf verschiedene Tabellen ausweicht, weiß ich ehrlich gesagt auch nicht so genau mangels tieferem Wissen über die Jet Access-DB-Interna. Allgemein kann ich sagen, daß Du das Problem der Sperrkonkurrenz mit der Einführung von einer Sperrtabelle im Access theoretisch nicht gelöst bekommst, weil Du die Isolations&Sperrkonflikte nur auf das Lesen/Schreiben in der Sperrtabelle verlagerst.
Auf der anderen Seite habe ich mal ein Access-Backend+ADO basiertes Ticketsystem für eine Arbeitsgruppe gebaut, wo ich eine lückenlose Vergabe von Ticketnummern realisiert habe. In mehreren Jahren Betrieb gab es nie ein Problem, die weiter oben beschriebene (beim SAP abgekupferte) Sperrlogik hat ihren Zweck erfüllt.

[Milvus]

Mit Normalisierung hat das streng genommen nichts zu tun, Normalisierung bezieht sich immer nur auf eine einzelne Relation. Nenne es besser "gutes Design".

Glaube von der 1. in die 2.
Ist ja aber auch egal an der Stelle

Danke schon mal für deine Hilfe. Besser als jetzt wirds mit Sicherheit