TAdoTable.Open() sprengt Arbeitsspeicherlimit

[Jasocul]

Ich würde das überhaupt nicht mit Delphi lösen, sondern auf dem SQL-Server einen Zugriff auf die Access-Datenbank einrichten. Anschließend wird der Abgleich auf dem SQL-Server gemacht. Dafür bietet sich eine Stored Procedure an. Das dürfte um ein Vielfaches schneller sein und um die Speicherverwaltung kümmert sich SQL-Server.
Allerdings setzt das Kenntnisse in SQL voraus. Falls die bei dir nicht ausreichend sind, solltest du dafür jemanden beauftragen. Das spart vermutlich dennoch mehr Zeit und Kosten ein, als du jetzt für den Umbau in Delphi investieren musst. Ich gehe aber davon aus, dass eine Firma, die einen SQL-Server betreibt, auch jemanden hat, der über ausreichend SQL-Kenntnisse verfügt. Somit blieben die Kosten zumindest im Haus.
Eine Stored Procedure auf dem SQL-Server kannst du dann auch mit Delphi starten.

[AxelO]

Zitat von Uwe Raabe:

Zitat von AxelO:

• Was ist mit dieser neuen Schnittstelle, FireDAC? Macht die das grundlegend anders?

Ein simpler Test mit einer TFDTable/TFDQuery Komponente für die betreffende Tabelle mit dem Speicherproblem sollte leicht zu bewerkstelligen sein. [...]

Ja schon klar. Ich wollte mir halt mit einer schnellen Nachfrage die Lernkurve ersparen. Wenn jemand definitiv gesagt hätte, dass FireDAC das auch nicht grundsätzlich anders macht, bräuchte ich erst gar nicht damit anzufangen.

[himitsu]

Wenn irgendwas "zusammenhängenden" Speicher benötigt, dann muß eben auch so ein großer Block aktuell im virtuellen Speicher frei sein.

Im Extremfall kann wird das schon bei durchschnittlich 300 bis 700 MB der Fall sein.

z.B. ein Programm belegt aktull nur 10 MB Arbeitrspeicher,
aber der Speicher ist extrem fragmentiert, also die paar MB sind schön verteilt und auch die DLLs liegen kreuz und quer überall rum,
dann kann es bereits so sein, dass in den möglichen 4GB nichtmal mehr 100 MB zusammengängend frei sind,
also es bereits knallt, obwohl nur 110 MB benötigt würden.

[Uwe Raabe]

Zitat von AxelO:

Wenn jemand definitiv gesagt hätte, dass FireDAC das auch nicht grundsätzlich anders macht, bräuchte ich erst gar nicht damit anzufangen.

Das kann man aber ohne weitere Kenntnisse über den bestehenden Code nicht sagen.

In der Regel ist es kein Problem, mit FireDAC auf Datenbanken mit Millionen von Datensätzen zuzugreifen, auch wenn nicht alle Datensätze in den Hauptspeicher des Client passen würden. Es kommt halt darauf an, wie man es verwendet. Mit den Standardeinstellungen ist das Öffnen einer TFDQuery/TFDTable überhaupt kein Problem, egal wie viele Datensätze es gibt. Ohne die Datenbank allgemein zur Verfügung zustellen bist du aber der einzige hier der das prüfen kann.

Wenn das reine Öffnen in einem Testprogramm sowohl mit FireDAC als auch ADO funktioniert, dann liegt das Problem eh woanders und bedarf einer tieferen Analyse der auslösenden Vorgänge.