|
Veteran
Beiträge: 127
 
| Hallo Alex,
die beschriebene Problematik betrifft nicht nur MS Access Anwendungen, sondern auch mit Visual Studio entwickelte Programme.
Ursache für das Verhalten ist der auf max. 2 GB begrenzte Prozessspeicher bei 32 bit Prozessen. Ab etwa 350 - 400 MB "Restspeicher" wird der Prozess instabil, bis hin zum Absturz. Fatal dabei ist, dass bei knappem Speicher teilweise Funktionen (kommentarlos!) nicht mehr ausgeführt werden. Der harmloseste Fall ist noch, dass ein Klick auf einen Button lediglich nichts bewirkt.
Aus diesem Grund habe ich in meine eigene MS Access Anwendung eine Speicherprüfung mit eingebaut, die das Öffnen weiterer Forms nicht mehr zulässt, sobald ein bestimmter Grenzwert unterschritten wird. Der Benutzer erhält dann einen Hinweis, Forms zu schließen oder das Programm neu zu starten.
Jedes geöffnete Form verbraucht - je nach Komplexität - eine bestimmte Menge an Speicher, der anschließend aber nur teilweise wieder freigegeben wird. Das erneute Öffnen des gleichen Forms verbraucht beim zweiten und dritten Öffnen entsprechend weniger Speicher als beim ersten Mal.
D.h. das mehrfache Öffnen des gleichen Forms macht nur wenig aus.
Öffnet man aber ständig neue Forms, dann hinterlässt jedes Form für sich einen Rückstand im laufenden Prozess, der sich entsprechend aufsummiert. Irgendwann ist der Speicher vollgelaufen und der Prozess muss zur „Räumung“ neu gestartet werden.
Beispielhaft ist das an den drei beigefügten Grafiken sichtbar :
001 = 1276 MB frei nach Programmstart
002 = acht weitere Komplexforms geöffnet, bis nur noch 430 MB verfügbar
003 = nur noch 1133 MB frei, nachdem alle Forms wieder geschlossen sind
Zusammen mit dem Professional Support von MS habe ich das im März 2012 herausfinden können, nachdem wegen der Umstellung von MS Access 2003 auf 2010 ständig Abstürze in meiner Anwendung aufgetreten sind. Wegen der damals neuen „Registertechnik“ waren jetzt halt bis zu zehn Komplexforms nebeneinander (mit Registern wechselbar) geöffnet.
Neben der Speicherüberwachung macht es ggf. Sinn, Funktionen komplett in neue Prozesse auszulagern, d.h. drei bis vier Anwendungen laufen parallel (z.B. laufender E-Mail Abruf oder laufende Outlook Synchronisation oder Datensicherung usw.) wird aus der MS Access Hauptanwendung mit einer anderen MS Access Anwendung gestartet. Dadurch verteilt sich der Speicherbedarf auf mehrere parallele MS Access Prozesse.
Das Einbinden von externen Datenbankmodulen und Forms belastet den Speicher des laufenden Prozesses im Übrigen genauso, wie wenn sich alle Forms und Module in einer einzigen DB befinden. D.h. es ist egal, woher das Form oder die Module stammen. Das habe ich getestet.
Hinweis zu neueren MS Access Versionen :
Access 2013 verbraucht etwa 10- 15 % mehr Speicher als die 2010 er Version. Die neue 2016 Access (Beta) ist wieder auf dem Niveau der 2010er angelangt, wobei die Forms nach dem Schließen aber nicht mehr so viel Speicher belegen wie noch in der 2010 er. D.h. es lassen sich (Stand Access Beta 2016) etwa 10 – 20 % mehr neue Forms Öffnen bis es knallt.
Eine theoretische Abhilfe wäre die Nutzung von 64 bit MS Access. Leider ist das Stand heute nicht praktikabel.
Es grüßt aus dem sonnigen Bensheim
Stephan Kraft
Anhänge
----------------
 001 Speicher nach Programmstart.jpg (109KB - 15 downloads)
002 Speicher mit ge��ffneten Forms.jpg (127KB - 11 downloads)
003 Speicher mit wieder geschlossenen Forms.jpg (124KB - 9 downloads)
| |
|