MaxLocksPerFile Error

Moin J0j0,

ja nee.... lass uns da noch ein bisschen dran feilen - das lass ich so nicht als Anleitung gelten.

[Als Tipp hätte ich ja nix gesagt...]

Was mir fehlt:

• Wer wo wann überhaupt diesen "Fehler 3072" ("Anzahl der maximalen Dateisperrungen überschritten") unter welchen Umständen zu sehen bekommen könnte
• Wer es sich denn überhaupt erlauben kann, eine MDB wie bei Variante 1 für sich ganz allein zu blocken
• Oder die umgedrehte Seite der Medaille: Welcher Access-Normal-User in einem handelsüblichen Firmennetz darf denn was-auch-immer im HKLM-Hive der Registry rumfuckeln?
• Welcher Fehler könnte mich nach zwei Minuten ereilen, wenn ich denn mal auf die Sahne haue und sage: "Hey, statt der vorgeschlagenen MaxLocksPerFile von 0x251c/9500dez stell ich mal 200000 ein, da bin ich dann auf der sicheren Seite."

( 2 Minuten später kommt: "Möglicherweise ist der Arbeitsspeicher für ... nicht ausreichend. Sichern Sie bitte noch nicht gespeicherte Daten..")

Ich weiss nicht, wo und bei was Dich diese MaxLocksPerFile-Grenze erwischt hat - bei einer Synchronisation, einem Massen-Update, einer Tabellenstrukturänderung oder einem Daten-Export.

In allen Fällen ist IMHO eher eine überlegte Portionierung der Transaktion (z.B. Commit nach je 5000 Datensätzen) sinnvoll oder, wenn es gar überhaupt nicht anders geht, eine Variante Deiner Variante 3
( aber nicht
..sondern explizit
)

Dennoch ganz klar - die Strategie der Redmonder PraktikantInnen (und diese Strategie können wir nicht unterlaufen) ist

• ALLE innerhalb einer Transaktion warum-auch-immer-gesperrten Datensätze bis zum Ende der Transaktion in ihrer vollen Satzlänge zu sperren.
• dafür gibt es einerseits die 9500 (=ANZAHL der Sperrungen und deren Verwaltung).
• dazu kommt allerdings der Arbeitsspeicherbedarf platt gesagt 9500 mal Datensätzlänge
• wenn Du NICHT explizit das UseTransaction-Property geändert hast (z.B. mit KlickiBunti bei den "Abfrageeingeschaften" einer "Aktualisungsabfrage" mit Setzen der Eigenschaft "Transaktionen verwenden" auf "Nein"), dann wird die Gesamt-Aktion ohnehin portioniert/mit mehreren Commit-Punkten versehen.
• aber eine vollständige Freigabe der Ressourcen erfolgt erst, enn explizit das oberste aktive DB-Objekt (im Normalfall CurrentDB()) destroyed wird. Sonst wird "nur" nach einem Commit/EndTransaction diese Sperren-verwaltung freigegeben.

Ein Hochsetzen der MaxLocksPerFile auf einen Mondwert entspricht de facto einem "Setze Transaktionen auf Nein", was auf deutscher bedeutet : "No way back - wenn irgendwann irgendwo beim Updaten von Satz 23456 von 25000 ein Fehler auftritt, dann brich ab und lass alles in dem Zustand, in dem es jetzt halt ist."

Na ja, egal... was ich nur sagen wollte: nach dem Lesen einer Anleitung sollte die geneigte Leserin/der gramgebeugte Leser eigentlich besser verstehen und wissen, an welchen Stellschrauben er drehen sollte und warum und wann lieber nicht.

Von daher meine Bitte:

• entweder "Anleitung" und dann aber noch etwas Butter bei die Fische mit dem Button "Editieren"
• oder umstufen als "Tipp".

Natürlich würde mich Möglichkeit A mehr freuen... ich will ja auch was lernen hier.

Grüße
Biber