Access 2003 Runtime unter Windows 8?

[André Wender]

Hallo zusammen,

wir setzen noch einige unter Access 2003 entwickelte Anwendungen ein.
Diese werden auf Windows XP PCs eingesetzt. Ab Mitte des Jahres wird es
einen Umstieg auf Windows 8 (nicht 8.1) geben. Jetzt haben wir bisher
leider erfolglos versucht, die Acc 2003 Runtime auf einem Test-PC zu
installieren. Unsere Anwendungen sind alle zweigeteilt: die auf einem
Fileserver befindliche MDBs beinhalten ausschließlich die Tabellen /
Daten, auf den Clients laufen unter der 2003er Runtime die eigentlichen
Anwendungen (Formulare, Abfragen etc. etc.).
Wir arbeiten nur mit nicht gebundenen Formularen, sämtliche
Datenzugriffe, halt die gesamte "Logik", wird via VBA-Code realisiert,
also nix mit Makros oder Assistenten erstelltes "Zeuchs" ;-)

Bisher haben wir die Installation der 2003er Runtime leider nicht
hinbekommen (natürlich als Admin angemeldet...), auch der Windows XP
Kompatibilitätsmodus brachte uns nicht weiter. By the way: den Einsatz
unserer Anwendungen unter einer "virtual machine" können wir leider
vergessen.

Ist estatsächlich nicht mehr möglich, Access 2003 Anwendungen unter Win
8 laufen zu lassen? Sicher, man könnte diese auf Acccess 2010 oder 2013
umstellen, dies wäre aber, wie uns damals eine Umstellung von Acccess
2.0 / 97 auf Acc 2003 gezeigt hat, mit nicht unerheblichem Aufwand
verbunden. Eine umstellung unseren Anwendungen auf "Web-Anwendungen"
wäre zwar recht charmant, dürfte aber noch länger dauern und ist damit
für uns momentan keine Option.

Tja, hat vielleicht von euch jemand eine Lösung parat?

André

[Winfried Sonntag]

Am 15.03.2014 schrieb André Wender:

> wir setzen noch einige unter Access 2003 entwickelte Anwendungen ein.
> Diese werden auf Windows XP PCs eingesetzt. Ab Mitte des Jahres wird es
> einen Umstieg auf Windows 8 (nicht 8.1) geben. Jetzt haben wir bisher
> leider erfolglos versucht, die Acc 2003 Runtime auf einem Test-PC zu
> installieren. Unsere Anwendungen sind alle zweigeteilt: die auf einem
> Fileserver befindliche MDBs beinhalten ausschließlich die Tabellen /
> Daten, auf den Clients laufen unter der 2003er Runtime die eigentlichen
> Anwendungen (Formulare, Abfragen etc. etc.).
> Wir arbeiten nur mit nicht gebundenen Formularen, sämtliche
> Datenzugriffe, halt die gesamte "Logik", wird via VBA-Code realisiert,
> also nix mit Makros oder Assistenten erstelltes "Zeuchs" ;-)

Sieht nicht so richtig gut aus:
http://www.microsoft.com/de-de/windows/compatibility/CompatCenter/ProductDetailsViewer?Type=Software&Name=Microsoft+Office+Access+2003+Runtime&ModelOrVersion=11&Vendor=Microsoft&Locale=1031%2C1036%2C3084%2C1041&LastSearchTerm=microsoft%2Boffice%2Baccess%2B2003%2Bruntime&BreadcrumbPath=microsoft+office+access+2003+runtime&TempOsid=Windows+8
Access 2003 Runtime wird unter W8 und höher nicht mehr unterstützt.

> Tja, hat vielleicht von euch jemand eine Lösung parat?

Access 2010 SP2 Runtime einsetzen. Bis Mitte des Jahres habt ihr noch
Zeit zu testen. Du kannst natürlich eine MDB mit A2010 laufen lassen,
nur kannst Du dann die A2010 Features nicht nutzen.

Servus
Winfried
--
Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
Access-FAQ: http://www.donkarl.com/AccessFAQ.htm
Access-Stammtisch: http://www.access-muenchen.de

[André Wender]

Am 15.03.2014 16:43, schrieb Winfried Sonntag:

>
> Sieht nicht so richtig gut aus:
> http://www.microsoft.com/de-de/windows/compatibility/CompatCenter/ProductDetailsViewer?Type=Software&Name=Microsoft+Office+Access+2003+Runtime&ModelOrVersion=11&Vendor=Microsoft&Locale=1031%2C1036%2C3084%2C1041&LastSearchTerm=microsoft%2Boffice%2Baccess%2B2003%2Bruntime&BreadcrumbPath=microsoft+office+access+2003+runtime&TempOsid=Windows+8
> Access 2003 Runtime wird unter W8 und höher nicht mehr unterstützt.
>
>> Tja, hat vielleicht von euch jemand eine Lösung parat?
>
> Access 2010 SP2 Runtime einsetzen. Bis Mitte des Jahres habt ihr noch
> Zeit zu testen. Du kannst natürlich eine MDB mit A2010 laufen lassen,
> nur kannst Du dann die A2010 Features nicht nutzen.
>
> Servus
> Winfried

Hallo Winfried,

naja, wir hatten sowas schon befürchtet. Aber Deinen Hinweis bzgl. der
Access 2010 Runtime ... njet, wir wollen keine A2010 Features nutzen,
das wäre, wenn denn unsere Anwendungen mit der 2010er Runtime laufen
würden, eine gute Lösung.
Aber um dann ggf. Änderungen, die ja immer mal vorkommen, an den
Anwendungen vornehmen zu können, müssten wir diese dann doch nach Acc
2010 konvertieren, um dann diese Änderungen mit einer Acc 2010
Vollversion durchführen zu können ... also die Vollversion von 2010 zu
kriegen, das wäre nicht das Problem, ich sehe nur darin ein Prob, unsere
Anwendungen auf Acc 2010 zu portieren. Von wegen nicht mehr unterstüzter
Funktionen etc. von Acc 2003 unter der 2010er Version.

Da wird dann wohl doch noch etliches an "Handarbeit" auf uns zukommen,
oder hast Du da ggf. andere Erfahrungen gemacht?

André

[Winfried Sonntag]

Am 15.03.2014 schrieb André Wender:

> naja, wir hatten sowas schon befürchtet. Aber Deinen Hinweis bzgl. der
> Access 2010 Runtime ... njet, wir wollen keine A2010 Features nutzen,
> das wäre, wenn denn unsere Anwendungen mit der 2010er Runtime laufen
> würden, eine gute Lösung.

Funktioniert gut, zumindest hatte ich das auf W7 und MDB als Front-
und Backend über einen längeren Zeitraum erfolgreich im Einsatz.

> Da wird dann wohl doch noch etliches an "Handarbeit" auf uns zukommen,
> oder hast Du da ggf. andere Erfahrungen gemacht?

Nein, es waren bei mir wirklich nur Kleinigkeiten. Am besten natürlich
aus einer neu erstellten ACCDB heraus auf die MDB zugreifen und alles
importieren. Ich hab allerdings nur DAO verwendet.

[Lars P. Wolschner]

=?ISO-8859-15?Q?Andr=E9_Wender?= <a.we...@bkaw.de>:

> Am 15.03.2014 16:43, schrieb Winfried Sonntag:

>>> Tja, hat vielleicht von euch jemand eine Lösung parat?
>>
>> Access 2010 SP2 Runtime einsetzen. Bis Mitte des Jahres habt
>> ihr noch Zeit zu testen. Du kannst natürlich eine MDB mit A2010
>> laufen lassen, nur kannst Du dann die A2010 Features nicht
>> nutzen.
>

> naja, wir hatten sowas schon befürchtet. Aber Deinen Hinweis
> bzgl. der Access 2010 Runtime ... njet, wir wollen keine A2010
> Features nutzen, das wäre, wenn denn unsere Anwendungen mit der
> 2010er Runtime laufen würden, eine gute Lösung.
> Aber um dann ggf. Änderungen, die ja immer mal vorkommen, an den
> Anwendungen vornehmen zu können, müssten wir diese dann doch
> nach Acc 2010 konvertieren, um dann diese Änderungen mit einer
> Acc 2010 Vollversion durchführen zu können ... also die
> Vollversion von 2010 zu kriegen, das wäre nicht das Problem, ich
> sehe nur darin ein Prob, unsere Anwendungen auf Acc 2010 zu
> portieren. Von wegen nicht mehr unterstüzter Funktionen etc. von
> Acc 2003 unter der 2010er Version.

Die Portierung von Access 97 oder noch älteren Versionen auf
Access 2003 war mit Abstand der größte Schritt, von Access 2003
nach Access 2010 lief es dann meiner Erfahrung nach vollkommen
unproblematisch.

> Da wird dann wohl doch noch etliches an "Handarbeit" auf uns
> zukommen, oder hast Du da ggf. andere Erfahrungen gemacht?

Eher nicht, wobei ich natürlich auch nicht alle Ecken
gleichermaßen gut kenne. Du kannst das *.mdb- bzw. *.mde-Format
auch erstmal beibehalten und brauchst nicht unbedingt auf das neue
*.accdb- bzw. *.accde-Format umzustellen, zumal es die alten
Probleme wie explodierende und gelegentlich auch defekte
Datenbankdateien auch bloß nicht behebt.

Wegen besserer Sharepoint-Server-Kompatibilität hat man den
bisherigen DAO.Field- und DAO.Recordset-Objekten DAO.Field2- und
DAO.Recordset2-Objekte zur Seite gestellt, die DAO aber
transparent erzeugt und einsetzt. Du brauchst deshalb nichts an
Deinem Code zu ändern, nur bei Abfragen auf der Basis von
Typename() mußt Du die neuen Klassenbezeichner berücksichtigen.

ADO wirst Du bei derartig alten Anwendungen vermutlich nicht im
Einsatz haben. Im Verbindung mit Datenbankservern gewinnt man
enorm an Performanz, weil man sämtliche SQLs durch den Server
abarbeiten lassen kann und nur die gewünschte Ergebnismenge zum
Client übertragen werden muß. Aber Server hast Du ja nicht.

--
Mit freundlichen Grüßen
Lars P. Wolschner

[Winfried Sonntag]

Am 15.03.2014 schrieb Lars P. Wolschner:

> =?ISO-8859-15?Q?Andr=E9_Wender?= <a.we...@bkaw.de>:

Was ist das denn?

> ADO wirst Du bei derartig alten Anwendungen vermutlich nicht im
> Einsatz haben. Im Verbindung mit Datenbankservern gewinnt man
> enorm an Performanz, weil man sämtliche SQLs durch den Server
> abarbeiten lassen kann und nur die gewünschte Ergebnismenge zum
> Client übertragen werden muß. Aber Server hast Du ja nicht.

Das geht mit DAO und PassThrough Abfragen genauso. ;)

[Ulrich Möller]

Hallo André,

die Access 2010 Runtime stellt wahrscheinlich die Lösung mit der größten
gemeinsamen Schnittmenge dar. Neu Features muß man ja nicht benutzen und
ein grober Test läßt sich ja mit einfachen Mitteln bewerkstelligen. Mit
einer Vollversion kann man dann die letzten Änderungen machen. Unter
Umständen muß noch das Menüsystem angepaßt werden, aber der Rest sollte
nahezu Problemlos laufen. Selbst das MDB-Format kann man Problemlos
weiter verwenden, egal ob DAO oder ADO.

Gruß
Ulrich

[André Wender]

Am 15.03.2014 23:22, schrieb Ulrich Möller:

>> Da wird dann wohl doch noch etliches an "Handarbeit" auf uns zukommen,
>> oder hast Du da ggf. andere Erfahrungen gemacht?
>>
>> André
>
> Hallo André,
>
> die Access 2010 Runtime stellt wahrscheinlich die Lösung mit der größten
> gemeinsamen Schnittmenge dar. Neu Features muß man ja nicht benutzen und
> ein grober Test läßt sich ja mit einfachen Mitteln bewerkstelligen. Mit
> einer Vollversion kann man dann die letzten Änderungen machen. Unter
> Umständen muß noch das Menüsystem angepaßt werden, aber der Rest sollte
> nahezu Problemlos laufen. Selbst das MDB-Format kann man Problemlos
> weiter verwenden, egal ob DAO oder ADO.
>
> Gruß
> Ulrich

Hallo Ulrich,

yo, jetzt habe ich dank eurer Infos schon einmal eine sehr gute
Diskussionsgrundlage. Ich werde dann unserer "Führung" die Portierung
unserer Acc2003er Anwendungen auf Acc2010 vorschlagen. IMHO dürfte dies
- insbesodere unter dem zeitlichen Aspekt - die eindeutig bessere Lösung
sein als die Umstellung auf Web-basierte Anwendungen. Damit kann man
sich ja später befassen, wir müssen halt "nur" relativ zeitnah (ich
hasse diesen Begriff...) eine Lösung finden.

Dann erst einmal vielen Dank für eure Tipps

André

[Dieter Liessmann]

Hallo André

mit den Setup Tools von SageKey sollte die 2003er Runtime auch unter Win8
laufen.
Werde das bei Gelegenheit testen.

Was aber fast noch wichtiger ist:
Beim Umstieg von XP auf Win7/8 ist das neue Memorymanagement des
Betriebssystems zu beachten!
Sicherheitsmechanismen von Win7/8 bzgl. des virtuellen Speichers verhindern,
dass hier gleiche Mengen und Blockgrößen wie unter XP adressiert werden
können. Das kann ggf. dazu führen, dass Access (egal ob 2003 oder 2010) in
eine Speicherproblem läuft.
Bei den von Dir beschriebenen Techniken die bei der Entwicklung zum Einsatz
gekommen sind halte ich die Gefahr für relativ gering, empfehle aber
unbedingt speziell in diese Richtung zu testen!

--
So long
Dieter

[Ulrich Möller]

Was soll das denn mit Access/VBA zu tun haben?

Ulrich

[Dieter Liessmann]

Ulrich Möller wrote:
> Was soll das denn mit Access/VBA zu tun haben?

Access benutzt wie alle anderen Applikationen auch virtuellen Speicher.
Access benutzt aber je nach Datenhintergrund der Formulare und
Unterformulare mehr Speicher als die anderen.
Daher spürt man dieses Problem am ehesten mit Access.

--
So long
Dieter

[Ulrich Möller]

Hallo Dieter,

das eine Anwendung Speicher benötigt, ist klar. Das ich als
VBA-Entwickler aber unmittelbar darauf Einfluss nehmen könnte, ob vom
Betriebssystem virtueller Speicher oder gar realer Speicher von Access
angefordert wird, halte ich für ein Gerücht. Ich muß mich darauf
verlassen, daß das vom Betriebssystem und von Access schon richtig
gehandhabt wird. Ich kann als Entwickler lediglich generell darauf
achten, ob meine Anwendung effizient/effektiv gestaltet ist oder nicht.
Aber das trifft wohl auf alle Anwendungen und Windows Versionen zu.

Das Access mit dem Speicher lausiger umgeht als andere vergleichbare
Anwendungsumgebungen, halte ich schlichtweg für ein Gerücht, eher im
Gegenteil - meine Erfahrungen sind hier eher positiver Art.

Die Anwendung von André basiert auf Access 2003 und Windows XP. Mal
abgesehen davon, inwieweit Access 2003RT noch unter Windows 8 zum laufen
zu bekommen beziehungsweise sinnvoll ist, sollte seine Anwendung
prinzipiell auch unter Windows7/8 laufen, wenn sie vorher keine Probleme
gemacht hat. Die Art der Verwendung und Zuteilung von Speicher spielt
hierbei keine Rolle mehr.

Allerdings würde ich wie schon erwähnt, auf eine neuere Version der
Access-Runtime migrieren, wenn das nicht durch das weggefallen von
verwendeten Features unmöglich wird. Der Rest der Anpassungen hält sich
in Grenzen, wenn nicht spezielle Windows-APIs genutzt werden, die nicht
mehr unter den späteren Windows Versionen unterstützt werden. Auch auf
die veränderten Sicherheitsrichtlinien sollte man einen Blick werfen,
insbesondere bei der Wahl der Ordner und der Registry-Einträge. Aber das
ist nichts unmögliches und normalerweise mit vertretbarem Aufwand zu
bewerkstelligen.

Gruß

Ulrich

[Dieter Liessmann]

Hallo Ulrich,

Ulrich Möller wrote:

> das eine Anwendung Speicher benötigt, ist klar. Das ich als
> VBA-Entwickler aber unmittelbar darauf Einfluss nehmen könnte, ob vom
> Betriebssystem virtueller Speicher oder gar realer Speicher von Access
> angefordert wird, halte ich für ein Gerücht. Ich muß mich darauf
> verlassen, daß das vom Betriebssystem und von Access schon richtig
> gehandhabt wird. Ich kann als Entwickler lediglich generell darauf
> achten, ob meine Anwendung effizient/effektiv gestaltet ist oder
> nicht. Aber das trifft wohl auf alle Anwendungen und Windows
> Versionen zu.

stimmt

> Das Access mit dem Speicher lausiger umgeht als andere vergleichbare
> Anwendungsumgebungen, halte ich schlichtweg für ein Gerücht, eher im
> Gegenteil - meine Erfahrungen sind hier eher positiver Art.

Kann und will ich nicht beurteilen. Access gehört aber zu den mächtigeren
Anwendungen und braucht schon von daher mehr Speicher, da ja auch eine
Datenbank durchaus größer wird als ein Word Dokument oder eine
Excel-Tabelle.

> Die Anwendung von André basiert auf Access 2003 und Windows XP. Mal
> abgesehen davon, inwieweit Access 2003RT noch unter Windows 8 zum
> laufen zu bekommen beziehungsweise sinnvoll ist, sollte seine
> Anwendung prinzipiell auch unter Windows7/8 laufen, wenn sie vorher
> keine Probleme gemacht hat. Die Art der Verwendung und Zuteilung von
> Speicher spielt hierbei keine Rolle mehr.

Falsch!
Ich mußte genau das leider gerade am eigenen Leib erfahren. Eine Applikation
(Access-Frontend, SQL-Backend)die seit vielen Jahren läuft, lief zuletzt in
der Version Access 2003 auf XP bzw. Server 2003.
Nach der Migration des Frontends auf Access 2010 kam es in der Testphase
beim Kunden immer wieder zu der Fehlermeldung "Nicht genug Speicher zum
Ausführen der ...".
Nach sehr intensiver Forschung war das Ergebnis der Unterschied im
Memorymanagement des Betriebssystems. Access hat also nichts damit zu tun,
viel mehr das Betriebssystem. Genau darauf wollte ich hinweisen und den Tipp
geben darauf zu achten.
Der Kunde kann nicht erkennen, dass das OS Schuld ist.
Dieses Problem wurde mir MS offiziell bestätigt nachdem ich Ihnen eine
Beispieldatenbank zugesendet habe in der sich der Fehler reproduzieren läßt.
Darin läßt sich auch erkennen, dass der Fehler mit Access 64 Bit nicht bzw
deutlich später auftritt, da hier eben mehr Speicher adressiert werden kann.

Hier die offizielle Beschreibung des MS-Supports:
---
Cause
When we load the report, we load each of the sub-report objects and this
requires that we allocate a block of memory for each one. In order to be
able to successfully complete the memory allocation, we must have a
contiguous block of memory that is equal to the allocation size that we are
attempting to make that is free for us to use. Unfortunately when the error
occurs we don't have a large enough block of free memory available to
service the request.

The Access process is consuming large amounts of virtual memory and the
error occurs because there isn't a large enough block of virtual memory left
for what Access attempts to allocate.

It appears that in this scenario, Windows 7 has more blocks of free virtual
memory available than Windows XP but the size of these free blocks are
smaller in Windows 7. This difference comes from a security change starting
with Windows Vista called Address Space Layout Randomization (ASLR) where
"the heap manager will create the heap at a random location to help reduce
the chance that an attempt to exploit a heap-based buffer overrun succeeds."
---

--
So long
Dieter

[Ulrich Möller]

Hallo Dieter,

so gesehen hast du natürlich mit dem letzten Punkt recht. Das
verschiedene Versionen eines Betriebssystems mit dem Speicher intern
anders umgehen, kann man von Außen erstmal nicht sofort erkennen. Aber
wenn meine Anwendung sagt, das nicht mehr genügend Speicher zur
Verfügung steht, ist das eine Ansage. Entweder ich passe dann meine
Anwendung an und sorge dafür, daß diese etwas besser mit den Ressourcen
umgeht, oder ich packe salopp gesagt ein bißchen mehr RAM in den PC. Die
natürlichen Grenzen einer 32Bit/64Bit-Anwendung kann man damit natürlich
nicht hinausschieben, die sind vom OS vorgegeben.

Ich glaube aber, daß das was du da beschreibst nicht der Standardfall
ist und eher eine extreme Ausnahme darstellt. Ähnliches habe ich schon
von Excel-Anwendern gehört, deren Berechnungen so komplex waren, daß
erst mit extremen Aufrüsten der Hardware und Umstellung auf 64Bit das
Problem beseitigt werden konnte.

Im "normalen" Alltag mit Access sind die Speicheranforderungen, auch
wenn es sich um eine DB-Anwendungen handelt, eher genügsam. Man kann das
mit dem Ressourcenmonitor von Windows 7 sehr gut nachvollziehen.

Gruß

Ulrich

[Karl Donaubauer]

Ulrich Möller wrote:
> ...oder ich packe salopp gesagt ein bißchen mehr RAM in den PC

Das bringt (fast) nichts, d.h. mit mehr RAM tritt die Speichermeldung
manchmal eine Spur später auf, aber meist spielt er keine Rolle,
weil es um Stapelspeicher geht, nicht um Arbeitsspeicher
generell.

> ...

> Ich glaube aber, daß das was du da beschreibst nicht der
> Standardfall ist und eher eine extreme Ausnahme darstellt.

> ...

Naa, ist es nicht. Es gibt haufenweise Forendiskussionen zu
diesem Fehler, weil es reicht, etliche Formulare bzw. UFos
gleichzeitig offen zu haben, was sehr viele Leute machen.

Auch zwei meiner Kunden hatten das Problem nach dem
Wechsel von A03 auf eine höhere Version bzw. auf Win 7.

Grob gesagt: Je höher die Access-Version und je neuer die
Win-Version, desto öfter tritt es auf. Die einen werden
(Stapel-)speicherfressener, die anderen wurden ab Vista
geiziger, wie von Dieter beschrieben.

--
Servus
Karl
*********
Access-FAQ: http://www.donkarl.com

[Ulrich Möller]

Ja ok. Wenn dem so ist, wovon ich jetzt mal ausgehe, gibt es denn für
diejenigen, die von diesem Problem betroffen sind eine allgemeine
Lösungsstrategie oder Tips, wie sie an das Problem herangehen bzw damit
umgehen könnten?

Ulrich

[Dieter Liessmann]

Ulrich Möller wrote:
> Ja ok. Wenn dem so ist, wovon ich jetzt mal ausgehe,

Danke Meister ;-)

> gibt es denn für
> diejenigen, die von diesem Problem betroffen sind eine allgemeine
> Lösungsstrategie oder Tips, wie sie an das Problem herangehen bzw
> damit umgehen könnten?

Tipps von MS:
RESOLUTION/LÖSUNG:
As we cannot mix 32bit installations of Office with 64bit Access the one
solution can be:
Redesign the database to use fewer resources. Changing to more of a load on
demand approach would help the situation. This link from FMS' website
provides a sample of a load on-demand for tab controls.
http://www.fmsinc.com/microsoftaccess/Performance/Forms/LateBinding.asp

Microsoft Access Performance Tip for Forms: Use Late Binding for Subforms on
Tab Pages
http://www.fmsinc.com/microsoftaccess/Performance/Forms/LateBinding.asp


Mein Vorgehen:
Die Formularsteuerung in meinen Applikationen baue ich komplett um. Ziel:
möglichst immer nur ein geöffnetes Formular/Bericht. Den Kunden musste ich
dann leider erklären, dass Sie durch den Einsatz von Neuer Hardware (mit
mehr CPU/Takt/RAM) und neuer Software langsamer werden und dafür auch noch
meinen Entwicklungsaufwand zahlen müssen. Mit schriftlicher Bestätigung von
MS gebe ich dafür Microsoft die Schuld. Das macht's für den Kunden kein
Stück besser aber für mich etwas erträglicher.

--
So long
Dieter