OutOfMemory Fehler abfangen

[Mavarik]

Ich kann mir momentan keine Situation vorstellen die es nötig macht 1Mio Datensätze oder mehr im Speicher zu halten?

Lade 100 - wahrscheinlich werden nur 40 auf einmal angezeigt... Wenn der User noch unten Scrollt lade nochmal 100 und vergiss die 1. 50... Fertig..

Abgesehen davon macht das FireDac sowieso - es sei den Du hast FetchAll gesetzt...

Oder mache es wie ein eMail Programm - lade 1000 Header und nur bei Bedarf, die entsprechende Daten die dahinter stecken...

Mavarik

[Aviator]

Ich werde es wohl so mal probieren müssen.

Aber es muss doch eine Möglichkeit geben, so einen Fehler generell abfangen zu können.

Ich greife übrigens nicht mit FireDac auf die Datenbank zu sondern benutze zum Zugriff auf die Datenbank direkt die sqlite3.dll. Die Daten werden, wie vorher beschrieben, in einer eigenen Datenstruktur aufbewahrt.

[mensch72]

Zitat von Aviator:

... 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.

[Aviator]

Ich schreibe ja ein Management Studio für SQLite. In unserer Firma nutzen wir MSSQL. Nur weiß ich ja nicht, wer irgendwann mal auf die Idee kommt und evtl. eine SQLite DB vom Netzwerk aus lädt. Ich würde das auch nicht machen, aber ich bin ja nicht der Endbenutzer. Wenn ich mal fertig bin mit dem Programm, dann dachte ich mir, dass ich es evtl. als Freeware anbiete. Nur bis zu diesem Tag wird es noch ein wenig dauern.

Aber trotzdem nochmal zur eigentlichen Frage zurück: Gibt es keine Möglichkeit, eine OutOfMemory Exception abzufangen und entsprechend nochmal etwas freizugeben? Kann doch nicht sein, dass ein Programm das einmal einen Speicherüberlauf produziert hat nur noch per TaskManager zu beenden ist.

[mensch72]

Vergleiche eine OutOfMemory Exeption mal mit "OutOfDiskSpace" , wo du anschließend noch etwas in einer LogDatei abspeichern willst...

Eine OutOfMemory Exeption kannst du eigentlich nur sinnvoll extern mit einem anderem (WatchDog)Prozess behandeln. Unter Win64 hat ja jeder Win32 seinen eigenen "32Bit-Speicherbereich". Wenn in einem Prozess also wegen Speichermangel nix mehr geht, kümmert sich ein anderer externer Prozess dann um das "geordenete" Management der Situation.

Eigene Datenstrukturen, Klassen, Pointer auf Arrayelemente... um eine eigene Logik für "VirtualTable", "VirtualArray" und "CachedCursor" kommt man da dann nicht herum, wenn man eben nicht UniDac oder FireDac nimmt, sondern direkt mit den DB-System ala SQlite3.dll arbeitet.



Ich weiß duraus bei 32Bit-Programmen wo von ich rede und kenne die "physischen Grenzen"...
-> wir "spielen" hier im Standard mit Tabellen, wo aktuell üblich !400Mio! Datensätze(bei uns alle Finanztransaktionsdaten von XY der letzten 10Jahre bis auf die Millisekunde genau) drin sind und da ist ein "select *" mit Scroll als Grid und/oder Chart absolut nix besonderes. Wir konnten das mit keinem normalen SQL basierten DBMS lösen und haben speziell dafür was eigenes mit einer aktuellen Verbeitungsrate von besser 8Mio/Records pro Sekunde bei bis 450Mio Records per Table noch immer mit Delphi2007 in Win32 entwickelt.


=> du wills aber was universelles machen.. ergo schau dir in den Sourcen von FireDac oder UniDac an, wie die das lösen und dann kannst du dich ja entscheiden ob&wie du dein SQlite ManagementTool unter Win32 realisierst

[hstreicher]

Google Delphi available memory

da es sich ja um ein 32 Bit Progamm handelt sollte das hier ausreichen

http://www.delphitricks.com/source-c...le_memory.html

oder das hier

http://stackoverflow.com/questions/7...4-gb-installed

[Sir Rufo]

Ich kenn das Management Studio vom SQL-Server und dort werden per Default 1000 Zeilen geladen. Will man die nächsten haben, dann drückt man Next Page und es werden die nächsten 1000 geladen.

Halte ich zunächst für völlig ausreichend. Die 1000 kann der Anwender auch noch selber verändern.

[Aviator]

Eine Grundeinschränkung von 1000 Zeilen wollte ich sowieso einbauen wenn jemand die Tabelle öffnet. Der User kann die Zahl danach natürlich erhöhen.

Entweder ich mache es so, dass der User selbst schuld ist wenn er so viele Datensätze lädt oder ich muss schauen, wie ich das abgefangen bekomme.

Die Links werde ich mir morgen anschauen. Würde es etwas bringen, vorher einen Count auszuführen und bei einer einstellbaren Zahl von Datensätzen gewarnt wird? Würde wahrscheinlich zu lange dauern und je mehr Stringspalten darin sind, desto früher läuft der Speicher ja auch über.

[Aviator]

Gerade noch eine Sache hierzu. Ich könnte dafür zwar ein neues Topic aufmachen, weiß aber nicht ob sich das lohnt, da ich die Antworten nicht kenne.

Ich wollte meine Anwendung sowieso so programmieren, dass ich diese auch als 64-bit Anwendung kompilieren kann. Auf was muss ich genau achten, wenn ich ein Programm sowohl als 32-bit als auch 64-bit kompilieren möchte? Muss ich andere Variablentypen verwenden, ganze Strukturen eines Programmes anpassen oder kann ich überall mit den selben Variablen arbeiten und es funktioniert trotzdem? Möchte natürlich die Vorzüge von 64-bit auch im Bezug auf Integer o.ä. nutzen und nicht nur einen größeren Adressraum für den Arbeitsspeicher haben.

Falls ich hierfür einen neuen Thread aufmachen sollte da das Thema evtl. umfangreicher ist als gedacht, dann sagt einfach bescheid.

[Bernhard Geyer]

Zitat von Aviator:

Möchte natürlich die Vorzüge von 64-bit auch im Bezug auf Integer ... nutzen

Die größe des Integers bleibt aber bei 64-Bit Systemen auch bei 32-Bit.
Und int64 kann man auch auf 32-Bit Systemen verwenden