[ADO] MaxRecords bzw. CacheSize

[MrSpock]

Hallo,

ich greife über ADO (ADOTable) und ODBC auf die KHK New CL zu.

Was ist der Unterschied der Eigenschaften MaxRecords und CacheSize?

[sx2008]

MaxRecords ist ein hartes Limit; d.h. auch wenn die Abfrage mehr Datensätze liefern könnte werden nur MaxRecords angezeigt.
Das ist z.B. nützlich wenn man grosse oder unbekannte Tabellen öffnet die potentiell Millionen Datensätze haben können.
Setzt man MaxRecords auf 500 ist sichergestellt dass die Anwendung nicht auf unbekannte Zeit blockiert weil zu viele Daten geschaufelt werden.

CacheSize lasse ich immer auf 1 weil ich früher damit seltsame Erfahrungen gemacht habe.
Das ist aber so lange her dass ich nicht mehr genau sagen kann was dabei schiefgelaufen ist.

[Perlsau]

Gerade ausprobiert, weil zuvor noch nie verwendet:

Setzt man MaxRecords auf einen Wert größer 0, wird in jedem Fall nur die gesetze Anzahl an Records geholt. Mehr geht nicht, bis MaxRecords auf einen größeren Wert gesetzt wurde.

Beläßt man dagegen MaxRecords auf 0 und setzt CacheSize z.B. auf 5 statt 1, sollte laut Online-Hilfe weitere Datensätze erst nachgeladen werden, nachdem sie angefordert wurden. Bei Aktivieren der Datenmenge sollten daher nur 5 Datensätze im Puffer stehen. Leider hab ich keine Ahnung, wie man das nachprüfen kann, denn beim erstmaligen Abruf von RecordCount fordert man ja gleich mal alle Datensätze an.

In der Online-Hilfe wird der Puffer auch als Zwischenspeicher beschrieben, der keine Datensätze enthalten soll, "die von anderen Benutzern der Daten gleichzeitig vorgenommen wurden" – doch m.W.n. gilt das generell für alle im Speicher von Datasets existierenden Datenmengen.

Ich gehe daher davon aus, daß es sich bei CacheSize einfach um die Menge an Datensätzen handelt, die bei Bedarf nachgeladen werden: Sobald man hinter den letzten geladenen Record kommt, werden weitere – in meinem Beispiel 5 – Datensätze nachgeladen. Meine Vermutung finde ich durch diesen Beitrag bei StackOverFlow bestätigt:

CacheSize

Delphi's and ADO's default cache size for a RecordSet is 1. That's 1 record. This works in combination with the cursor type. The cachesize tells the RecordSet how many records to fetch and store at a time.

When you issue a command like Next (really MoveNext in ADO) with a cache size of 1, the RecordSet only has the current record in memory, so when it fetches that next record, it must request it from the provider again. If the cursor is not Static, that gives the provider the opportunity to get the latest data before returning the next record. So, a size of 1 makes sense for Keyset or Dynamic, because you want the provider to be able to get you the updated data.

Obviously, with a value of 1, there's communication between the provider and RecordSet each time move the cursor. Well, that's overhead that we don't want if the cursor type is static. So, increasing your cache size will reduce the number of round trips between the RecordSet and the provider. This also increases your memory requirements, but it should be faster.

Also note that with a cache size greater than 1 for Keyset cursors, if the record that you want is in the cache, it won't request it from the provider again, which means that you won't see the updates.

[MrSpock]

Ich kann das so nicht bestätigen, was aber durchaus an der ODBC Treiber Installation von SAGE KHK New Classic Line liegen kann.

Ich habe in der ADOTable Komponente einmal sowohl MaxRecords als auch CachSize auf 100 gesetzt. Dann bin ich die Tabelle in einer Schleife durchlaufen und habe alle ca. 5400 Datensätze lesen können. In sofern wird MaxRecords hier nicht als wirklich harte Grenze interpretiert.

Mein Problem ist, dass eine Anwendung beim Kunden seit der Umstellung auf die neue New Classic Line beim Lesen der Kundetabelle einfach mit dem Fehler "Out of memory" hängen bleibt. Das passiert auf meinem älteren Rechner nicht. Beide nutzen Win 7 64 Bit. Es scheint so zu sein, dass beim Aufruf von RecordCount die gesamte Tabelle in den Speicher geladen wird, bzw. das System versucht diese zu laden. Ich habe deshalb RecordCount durch eine ADO SQL Abfrage an den Server ersetzt. Außerdem habe ich CacheSize auf 100 gesetzt und MaxRecords jetzt wieder von 100 auf 0 zurückgesetzt.

Bin gespannt, ob es das Problem löst.

[Perlsau]

Zitat von MrSpock:

Ich kann das so nicht bestätigen, was aber durchaus an der ODBC Treiber Installation von SAGE KHK New Classic Line liegen kann.

... was ich wiederum mangels "SAGE KHK New Classic Line" nicht beurteilen kann ...

Zitat von MrSpock:

Ich habe in der ADOTable Komponente einmal sowohl MaxRecords als auch CachSize auf 100 gesetzt. Dann bin ich die Tabelle in einer Schleife durchlaufen und habe alle ca. 5400 Datensätze lesen können. In sofern wird MaxRecords hier nicht als wirklich harte Grenze interpretiert.

Eine Schleife benötigte ich bislang nicht, um Datensätze via TAdoTable zu lesen. Gewöhnlich setzt man in TAdoTable doch einfach die Connection und wählt dann eine der verfügbaren Tabellen aus. Ich habe das hier mit einer Sichten-Tabelle (View) im SQL-Server (Treiber: SQLOLEDB.1) unter Delphi 2009 getestet. Wenn ich MaxRecords auf 5 stelle, erhalte ich nur die ersten 5 Records und komme da auch nicht an weitere Records ran, egal was ich anstelle.

Könntest du das mit der Schleife mal etwas näher erläutern?

Zitat von MrSpock:

Mein Problem ist, dass eine Anwendung beim Kunden seit der Umstellung auf die neue New Classic Line beim Lesen der Kundetabelle einfach mit dem Fehler "Out of memory" hängen bleibt. Das passiert auf meinem älteren Rechner nicht. Beide nutzen Win 7 64 Bit. Es scheint so zu sein, dass beim Aufruf von RecordCount die gesamte Tabelle in den Speicher geladen wird, bzw. das System versucht diese zu laden. Ich habe deshalb RecordCount durch eine ADO SQL Abfrage an den Server ersetzt. Außerdem habe ich CacheSize auf 100 gesetzt und MaxRecords jetzt wieder von 100 auf 0 zurückgesetzt.

Scheint so, als ob es ich um sehr große Tabellen handelt, eventuell mit großen Blob-Feldern? Defaultmäßig steht CacheSize auf 1, was bedeutet, daß bei Anforderung immer nur ein weiterer Datensatz geholt (fetched) wird. Möglicherweise hilft es in deinem Fall, CacheSize auf einem eher niedrigen Wert zu belassen statt gleich 100 Datensätze auf einmal in den Cache (Speicher) zu laden.

Die Ado-Komponenten scheinen mir, der ich durch FibPlus und IbDac verwöhnt bin, doch eher unkomfortabel zu sein. Dessen ungeachtet kann ich selbst auch nicht immer auf Ado verzichten, weil mir das Geld für bessere, modernere Kompos fehlt. Beim nächsten finanziellen Überschuß schaffe ich mir UniDac an, damit kann ich dann wohl die meisten Datenbanken abdecken.

[MrSpock]

Zitat von Perlsau:

Scheint so, als ob es ich um sehr große Tabellen handelt, eventuell mit großen Blob-Feldern? Defaultmäßig steht CacheSize auf 1, was bedeutet, daß bei Anforderung immer nur ein weiterer Datensatz geholt (fetched) wird. Möglicherweise hilft es in deinem Fall, CacheSize auf einem eher niedrigen Wert zu belassen statt gleich 100 Datensätze auf einmal in den Cache (Speicher) zu laden.

Die Ado-Komponenten scheinen mir, der ich durch FibPlus und IbDac verwöhnt bin, doch eher unkomfortabel zu sein. Dessen ungeachtet kann ich selbst auch nicht immer auf Ado verzichten, weil mir das Geld für bessere, modernere Kompos fehlt. Beim nächsten finanziellen Überschuß schaffe ich mir UniDac an, damit kann ich dann wohl die meisten Datenbanken abdecken.

Nein, die Tabellen sind gar nicht wirklich groß und enthalten keine BLOB Felder, dennoch bricht das Programm weiter mit "Out of Memory" ab. Bei mir, wo die Tabellen alle auf dem lokales Rechner sind, funktioniert alles einwandfrei. Beim Kunden, wo die Tabellen auf verschiedenen Servern liegen, kommt es zu dem Fehler.

Ich weiß noch nicht genau wann der fehler auftritt. Das Öffnen der Tabelle (mit Open) funktioniert ohne Probleme. Dann frage ich mit der ADO SQL Abfrage die Anzahl der Datensätze in der Tabelle ab. Auch das funktioniert. Dann laufe ich in einer Schleife bis zum EOF durch. Offensichtlich wird aber beim Zugriff auf den ersten Datensatz irgendwie der Fehler ausgelöst.

[Dejan Vu]

War da nicht etwas mit client/serverseitigen Cursors (was ist nur die Mehrzahl von Cursor? )

Zitat:

Das Öffnen der Tabelle (mit Open) funktioniert ohne Probleme. Dann frage ich mit der ADO SQL Abfrage die Anzahl der Datensätze in der Tabelle ab.

Andersherum geht es auch.

Ich kenne beim ersten Zugriff auf ein ADO-Record bzw. Feld eine Nil-Exception, aber das war ADO 2.6 (glaube ich). Dieses Problem sollte nicht mehr auftreten.

Welche DB? Access?

[Perlsau]

Zitat von Dejan Vu:

Welche DB? Access?

Steht doch bereits oben im Eröffnungsposting.

[Dejan Vu]

Zitat von Perlsau:

Zitat von Dejan Vu:

Welche DB? Access?

Steht doch bereits oben im Eröffnungsposting.

Sieht man beim Schreiben nicht.

[MrSpock]

Habe gestern noch einmal ein kleines Testprogramm geschrieben. Egal, was ich unter MaxRecords oder CacheSize einstelle, der Treiber lädt immer alle Datensätze. Dann habe ich versucht über ein ADODataSet mithilfe von LIMIT die Anzahl zu beschränken, aber das kommt über dn Umweg ADO -> ODBC -> KHK My SQL wohl nicht beim Server an. Er ignoriert auch das LIMIT.

Jetzt habe ich die Anzahl der Datensätze aus der Kundentabelle über die KundenId blockweise Eingelesen, damit werden natürlich nur noch die Datensätze aus dem Block (z.B. so

Zitat:

SELECT * FROM Kunden WHERE Kundennummer >= '0000000000' AND Kundennummer < '5000000000'

geladen. Mal schauen, ob das jetzt funktioniert. Auch die Einstellungen zum asynchronen Lesen scheinen ignoriert zu werden.

In dem Testprogramm habe ich noch das Zeitlimit von 30 auf 60 Sekunden gesetzt, möglicherweise kann auch das noch helfen. Wobei die Fehlermeldung nicht "Timeout" sondern "Out of Memory" ist.

Das ist alles etwas verwirrend.