Row limit: Nur 10.000 Datensätze

Du hast in einem Access-ADP das Problem, dass du eine große Menge an Datensätzen anzeigen oder verarbeiten (UPDATE/INSERT/DELETE) willst, aber dass immer nur maximal 10.000 Datensätze angezeigt bzw. verarbeitet werden.

Der einfache Grund hierfür ist, dass Access per Standardeinstellung die Anzahl der bearbeiteten Datensätze auf 10.000 begrenzt.

Das Problem lässt sich mit zwei verschiedenen Ansätzen lösen. Die einfache Lösung ist, die Standardeinstellung von Access den eigenen Bedürfnissen anzupassen. Dazu kann man über das Menü Extras-Optionen-Weitere-Client/Server-Einstellungen-Vorgabe der max. Datensätze einfach einen anderen geeigneten Wert einstellen. Diese Vorgabe gilt jeweils nur für die aktuelle Datenbank.

Diese Änderung der Standardeinstellung lässt sich auch über VBA-Code vornehmen, indem man über die SetOption-Methode die Row Limit-Option verändert. Der folgende Beispielcode demonstriert dies (das Row Limit wird auf 500 Datensätze reduziert):

Call Application.SetOption("Row Limit",500)

Bevor man das Thema damit komplett abhakt, sollte man aber bedenken, dass das Access-Team von Mircosoft diese Voreinstellung nicht einfach nur vorgenommen hat, um uns arme Entwickler zu ärgern, sondern dass diese Voreinstellung durchaus ihre Berechtigung hat. Überleg mal; wer will ersthaft eine Liste mit mehr als 10.000 Datensätzen am Bildschirm durchgehen, oder sich gar duch soviele Datensätze in einer Einzelansicht klicken? - Normalerweise niemand! Weiterhin sollte man bedenken, dass mit einer globalen Änderung dieser Option der SQL-Server dazu gezwungen wird eine Menge Datensätze zum Access-Client zu schaufeln, für die sich dort niemand interessiert. Das belastet den Server und das Netzwerk völlig unnötig.

Anstatt das Row Limit für alle Abfragen in den Access-Standardeinstellungen zu verändern kann man auch in alle Stored Procedures auf dem SQL-Server, die Änderungen an dem Datenbestand vornehmen den Rowcount (Synonym für die Row Limit-Option in Access) per T-SQL setzen. Die entsprechende T-SQL-Anweisung lautet einfach:

SET ROWCOUNT 0

Der Wert 0 für den Rowcount deaktiviert die Beschränkung der betroffenen Datensätze vollständig. D.h. es werden immer alle Datensätze verarbeitet, die den jeweiligen Kriterien entsprechen. Wenn man den Rowcount innerhalb einer Stored Procedure setzt, gilt der jeweilige Wert nur innerhalb der Stored Procedure, nicht für die gesamte Verbindung.

Natürlich kann man auch vor AdHoc-SQL-Statements, die man über die Connection des ADPs ausführt, den Rowcount, wie oben beschrieben, per T-SQL auf einen geeigneten Wert setzen. Allerdings möchte ich dieses Vorgehen nicht empfehlen, da man das dann vor jedem einzelnen SQL-Statement berücksichtigen muss und das meiner Meinung nach zu fehlerträchtig ist. Wenn man also von Ad-Hoc-SQL gebrauch macht um Daten zu ändern, sollte man besser dafür sorgen, dass das Row Limit für die ganze Verbindung des ADPs immer korrekt eingestellt ist. Die bessere Alternative ist natürlich grundsätzlich sämtliche DML-Aktionen ausschließlich über Stored Procedures auszuführen.

Ich würde in jedem Fall für alle Stored Procedures, die Daten verändern immer explizit den ROWCOUNT innerhalb der Stored Procedure auf 0 setzen, wie oben beschrieben. Damit ist sichergestellt, dass die Stored Procedure als autarke Einheit immer funktioniert und nur von eventuellen Eingabeparametern, aber nicht von gobalen Einstellungen, wie dem Rowcount der Connection, abhängig ist.

Realisierung:
Private Sub Form_Open(Cancel As Integer)
MaxDatensätze = Application.GetOption("Row Limit")
Application.SetOption "Row Limit", 0
End Sub

Private Sub Form_Close()
Application.SetOption "Row Limit", MaxDatensätze
End Sub

Quelle: www.codekabinett.com