Office: (Office 2016) Fehler 3035: nicht genügend Systemresourcen

Hallo zusammen

Ich habe 2 Access-Anwendungen, die als accdb seit über 10 Jahren sehr stabil und fehlerlos laufen. Inzwischen läuft die Anwendung unter Win10 1709, 64-Bit (16 GB RAM) und Office 2016, 32-Bit (Version 1804, Build 9226.2156 Klick-und-Los). Die Backend habe eine Grösse von 150 MB bzw. 350 MB. Die Frontend 130 MB bzw. 50 MB.

Nun erscheint seit einigen Monaten an verschiedenen Stellen (Fakturierung auslösen, Umsatzberichte etc.) die Fehlermeldung 3035 "nicht genügend Systemressourcen" ohne dass sich an der Programmierung oder der Datenmenge etwas nennenswertes geändert hat. Auch an den Compis hat sich nichts verändert. Ich vermute deshalb, dass der Upgrade auf Win10-1709 oder die Updates von Office/Access eine Rolle spielen könnten.

Da die Anwendungen auch bei verschiedenen Firmen laufen und auch dort die Fehlermeldung auftritt, ist die Erhöhung des maximalen Speichers keine Option. Da hätten die Admins wahrscheinlich keine Freude.

Ich bitte Euch deshalb um Hilfe bei der Behebung dieses Fehlers. Hat jemand auch plötzlich diese Fehlermeldung bei einer stabilen Anwendung und gibt es eine Ursache für das Auftreten?

Gruss und vielen Dank
Franz

:)

 

In welchen Kontext kommt es zu dem Fehler?
Problematisch sind mitunter Abfragen mit integrierten Domänen oder User Funktionen die größere Datenmengen verarbeiten.

Hast du mal versucht, den Code nach der Fehlermeldung weiterlaufen zu lassen?

 

Hallo Markus

Danke für Deine Hilfe. Ich schildere einmal einen konkreten Fall. Über eine VBA-Funktion werden Rechnungsdaten aus der Anlassverwaltung in die Fakturierungstabellen geschrieben. Zuerst wird über eine Anfügeabfrage der Rechnungsstamm erstellt. Anschliessend erfolgt über eine weitere Anfügeabfrage die Erstellung der Rechnungspositionen. Diese Funktion läuft schon Jahre ohne Probleme. Seit einigen Monaten kommt es beim Schreiben der Rechnungspositionen zum Fehler 3035. Im konkreten Fall werden lediglich 8 Rechnungspositionen eingetragen. Die Anfügeabfrage lautet wie folgt:
Code:

Vielen Dank für die weitere Unterstützung
Franz

 

Hallo Franz,

möglicherweise hat das Problem mit dem Formularbezug zu tun. Pack den Datumswert mal in eine Variable und pass dein Statement an. Prüfe auch den Ablauf bei geschlossenem Form. Denke, es ist einen Versuch wert.

 

... obwohl da allerhand Unsinn getrieben wird. Wenn es trotzdem "funktioniert", darf man da von Gnade sprechen (die endlich ist).
Code:

Betrachtung des Gruppieren-Teils:
- Die Feldliste ist genau so lang wie im SELECT-Teil. Wer in der Lage ist, über diesen Fakt an sich nachzudenken: Entweder ist dieser Aufwand schlicht gedankenlos eingefügt und überflüssig, oder es werden über die unzähligen JOIN's Daten vervielfältigt, die dann durch das Gruppieren wieder duplikatfrei gestellt werden sollen. Effizient wäre auch jenes nicht.
Ein Gruppieren über Now(): Wie kann da eine nachvollziehbare Verwendungsbegründung lauten?
Riesenfeldliste und berechnete Felder: Über eine Indexnutzung muss man da nicht weiter nachdenken.
- Bei dem IIF-Konstrukt: Da fehlt eine Tabelle hinsichtlich datenbankgemäßes Arbeiten.

Also: Mit einigen Umformulierungen ließe sich hier ordentlich unnützer Aufwand sparen, womit dann auch die Ressourcen von Access in der Berechnung weniger beansprucht werden sollten.

 

Puh, du hast ja eine interessante Schachtelung bei den Joins.

(IJ((IJ)LJ))IJ(IJ(IJ(IJ)))

IJ = Inner Join
LJ = Left Join

Mich wundert dass das überhaupt geht. Hier ein Auszug aus der VBA Hilfe zum Thema Inner Join:

Nach dem du nicht einmal einen einzigen Alias eingesetzt hast, nehme ich jetzt mal an, dass die Abfrage mit Hilfe des Assistenten erstellt wurde. Durch die Klammerung wird die Abfrage so erst möglich. Ich bezweifle aber, dass der Aufbau sinnvoll ist.

Ich würde mal versuchen, eine korrekte Abfrage ohne diesen Assistenten zu erstellen. Ab einem gewissen Schwierigkeitsgrad sollt man den Assistenten meiden. *wink.gif*
Außerdem Gruppierung und Distinct - wer kommt auf so einen Idee?

 

Hallo Franz,

hast Du Dein Problem gelöst bekommen?

Ich habe das gleiche Problem wie Du seitdem Umstieg auf W10 (x64).
Die Anwendung ist in Acc2010/32Bit programmiert und lief unter W7 (x64) ohne Probleme.

Ich habe nun durch verschiedene Test folgendes festgestellt:

1.) Ich öffnen die Anwendung im Netzwerk mur auf PC1 und kann die betroffene Abfrage so oft ich will ohne Fehler ausführen.

2.) Ich öffnen an einem zweiten PC (PC2) nur die DB und mache nicht einmal eine Änderung an den Daten sondern schließe die DB wird. Die DB hat dadurch nun ein neues Änderungsdatum erhalten.

3.) Ich gehe wieder zurück zu PC1 wo die Anwendung immer noch geöffnet ist. Führe ich nun die Abfrage wieder aus kommt der Fehler 3035.

4.) Schließe ich die Anwendung auf PC1 und starte dieses erneut, kann ich die Abfrage wieder ohne Fehler aufrufen.

5.) Nun kommt noch die Krönung:
Wenn ich nach Punkt 1) und Punkt 2) die DB auf PC1 zusätzlich zur Anwendung öffne und eine Änderung mache und wieder schieße kann ich die Abfrage ohne Fehler weiterhin in der Anwendung ausführen.

Dadurch komme ich immer mehr zur Überlegung, dass das nichts mit der Abfrage zu tun hat, sondern mit Windows 10 bzw. einer Vieren scann- und oder Indexscann Funktion (Punkt5) von Windows 10.

Hat hier jemand einen Ähnlichen Effekt und eine Lösung dafür.

Gruß
Thomas

 

Eventuell besteht dieses Problem:

https://www.heise.de/newsticker/meld...s-4587328.html

 

Hallo,

den Fehler habe ich auch schon diese Woche bei einem Kunden gehabt.

Das beschriebene Problem gibt es aber schon länger.

Grüße
Thomas

 

> 2.) Ich öffnen an einem zweiten PC (PC2) nur die DB

Dem lässt sich nicht mal entnehmen ob es eine FE/BE Aufteilung gibt.
FE impliziert, dass selbiges auf dem Client-Computer abgelegt ist
und exklusiv benutzt wird. Ein FE im Netzwerk, das von mehreren
PCs aus verwendet wird, ist inakzeptabel.

 

Frontend liegt lokal.
Backend liegt auf einem Server zentral.
Alles andere ist nicht nur inakzeptabel sondern funktioniert einfach auch nicht :-)

 

#8 gelesen???

 

Ja, da habe ich in #9 darauf geantwortet.

 

DB soll dann das Backend sein? (Solche schwammigen Aussagen sind immer sehr vertrauensbildend.)

Das Öffnen des Backends selber beim Client gehört zum normalen Arbeitsprozess?

 

DB habe ich als Abkürzung für Datenbank verwendet.
In meinem Sprachgebrauch ist damit immer ein Backend gemeint.
Nach 22 Jahren Accessanwendungsentwicklung habe ich diese Grundregel der Trennung in Backend und Frontend schon gleich am Anfang gelernt und berücksichtig. Da kann man mal wieder sehen, wenn man im Tunnel ist setzt man bestimmt Sachen voraus, die für einen Dritten dann nicht klar genug beschrieben sind - sorry dafür.

Die Anwendung=Frontend ist auf ca. 15 PC´s installiert.
Die DB=Datenbank=Backend ist zentral auf einem Server abgelegt.

Normal wird die DB=Datenbank=Backend von den lokalen Anwendungen=Frontend geöffnet und geändert.

In diesem Umfeld hat sich das beschriebene Verhalten auch gezeigt.

Um auszuschließen, dass die Anwendung=Frontend selbst den Effekt verursacht, habe ich nur zu Testzwecken die DB=Datenbank=Backend von einem zweiten PC aus mit einer Accessvollversion geöffnet und gleich wieder geschlossen. Als KEINE Daten in der DB=Datenbank=Backend angelegt, gelöscht oder geändert. Der beschrieben Effekt ist aber der gleiche.

Gruß
Thomas