|
Veteran
Beiträge: 127
 
| Eine frisch geladene DokuWork (MS Access-) Anwendung stellt zu Beginn der Instanz (direkt nach Programmstart) unter MS Access 2010 rund 1,2 GB freien Speicher bereit.
Lädt man die gleiche MS Access Anwendung mit Access 2019 sind es stattdessen nur knapp 0,9 GB. Ab 0,6 GB Restspeicher muss man Forms schon zwangsweise schließen, um das System stabil zu halten. D.h. im günstigsten Fall lassen sich mit Access 2019 zwei bis drei Forms parallel offen halten (statt 6 - 8 mit Access 2010).
Die von Microsoft mit diesem Verhalten (exorbitanter Speicherverbrauch und 64 bit als Office Standardinstallation) forcierte Zwangsumstellung der bestehenden Access Applikationen von 32 bit auf 64 bit wird noch einiges an Heulen und Zähneklappern auslösen.
Es ist ja nicht so, dass man einfach einen Parallelbetrieb einer einzigen Programm-Datenbank (Frontend) möglich machen kann. Das geht nur, wenn keinerlei ActiveX Komponenten verwendet werden. D.h. bei Komplexanwendungen (andere verwenden keine ActiveX Komponenten) muss man für jede Betriebsweise (32 und 64 bit) eine eigene (zu pflegende) Anwendung bereitstellen. Irgendwann in 20 Jahren, wenn es keine Kunden mit 32 bit Office mehr gibt, kann man sich dann den Zusatzaufwand der doppelten Pflege einsparen.
Alleine dem Kunden klar zu machen, dass es bei der Installation einer Access Applikation darauf ankommt welches Office installiert ist (32 bit oder 64 bit) stellt eine zusätzliche Hürde dar.
Der GAU tritt dann ein (heute erlebt), wenn auf einem Kundensystem eine Access Anwendung mit der 32 bit Runtime installiert ist und der Kunde dann Office 2016 64 bit installiert. In dem Fall wird die 32 bit MS Access-Runtime 2010 so zerschossen, dass weder eine Deinstallation noch eine Neuinstallation der Runtime möglich ist. Die 32 bit Access Anwendung läuft natürlich auch nicht mehr.
Ganz großes Kino.
Edited by sks 21.11.18 15:10
| |
|
Access 2019 --> Ressourcebbedarf 32 bit