... In diesem Fall müsste z.B. immer eine Verbindung zur Datenbank bestehen. Wenn diese auf einem Netzlaufwerk liegt, kann es auch schonmal vorkommen, dass das Netzwerk nicht funktioniert. In dem Fall wäre ich bei deiner Lösung in den aktuell angezeigten Zeilen gefangen. Mit meiner Lösung könnte ich weiterhin alle Daten durchsuchen, scrollen und bspw. auch kopieren.
Gibt es denn keine Möglichkeit, ein OutOfMemory Fehler abzufangen und die Instanzen wieder freizugeben die den Speicher belegen?
Ähhh, wenn alles in
RAM laden nicht will, bleibt doch nur der live Zugriff auf die Daten(bank), welche schrittweise(mein Beispiel) oder blockweise(siehe
SQL Beispiel mit den 1000) je nach Bedarf live nachlädt.
Wenn die Datenquelle extern/unsicher ist, dann muss man sich eben lokal auf Disk (und nicht im
RAM) eine Kopie als Zugriffscache erzeugen (also lokale SQliteDB holt sich zunächst per "BatchMove" gemäß UserSQL das was gewünscht ist und speichert das als "ViewResultTable" lokal. Anzeige und Verarbeitung gehen dann Schrittweise/Bockweise mit einer
Query auf diese lokale "ViewResultTable".
Datenbanken im Netzwerk per FileZugriff sollte man nicht (mehr) machen. Dafür nehme man einen echtes
DBMS was die Clients direkt per Netzwerkprotokoll anbindet.
Wir nehmen im Netzwerk MS-SQLexpress (nur ganz wenig hat bis jetzt den großen MS-
SQL Server wirklich gebraucht und genutzt) und als lokales "
SQL" meist sogar noch die "
access.mdb" Files (SQlite weil portabel für MAC und Mobile aber jetzt für alles neue mit FMX).
Speziell im MobileBereich machen wir immer einen Kompromiss zwischen offlinefähig gecacheten lokalen (Stamm/View)Daten und 100% aktuellen Gesamt(Live)Daten auf den Servern mit online Zwang.