Office: (Office 2000) Mehr Datenbanken können nicht geöffnet werden

Hallo,

in unserer Anwendung kommt überlicherweise wenn 8-10 Programmbereiche gleichzeitig geöffnet werden irgendwann die Meldung "Mehr Datenbanken können nicht geöffnet werden". Das ist zu verschmerzen. Bei vereinzelten Anwendern kommt diese Meldung allerdings schon bei 5 Programmbereichen (Haupt-Formularen teilweise mit Unterformularen) und dies ist störend.

Die Anwendung besteht aus Frontend und ca. 20 Backend-Datenbanken mit insgesamt ca. 600 Tabellen. Wenn die Backend-Tabellen über ODBC verknüpft auf einen MySQL-Server liegen, kommt die Meldung nie, es können nahezu beliebig viele Programmbereiche geöffnet werden. Bis zu 30 habe ich gestestet, da kommt auch ein Extrem-Anwender niemals hin.

Jetzt meine Frage, gibt es irgendwie eine Möglichkeit Access zu beeinflussen, dass die Meldung "Mehr Datenbanken können nicht geöffnet werden" erst später kommt. Meine Hoffnung wäre ein Registry-Eintrag oder ähnliches.

Das weniger Tabellen, Formulare etc. öffnen, zum Erfolg führt weiß ich selber auch.

Für Tipps oder Ideen wäre ich sehr dankbar.

:)

 

Die Fehlermeldung ist leider etwas schlecht formuliert. Mit "Datenbanken" sind dabei meistens DAO.Database-Instanzen gemeint.
Verwendest du oft CurrentDb oder DLookup & Co? Dann wird nämlich jedes Mal eine DAO.Database-Instanz erzeugt - das heißt aber nicht, dass "OpenDatabase" so oft verwendet wird.

Versuche einmal immer nur eine CurrentDb-Instanz zu nutzen.
Ein übliches Vorgehen ist dabei ein Vorschlag von Michael Kaplan:

Prinzip:
Code:

Falls du das Dlookup-Zeugs oft einsetzt, könntest du diese durch Recordset-Funktionen ersetzen.

Weiters solltest du prüfen, ob die Recordsets überall im Code geschlossen werden.

Du findest aber bestimmt noch massenweise Infos mit Google & Co., wenn du nach "Mehr Datenbanken können nicht geöffnet werden" suchst. *wink.gif*

 

\@Josef

für CurrentDB wird eine natürlich eine globale Variable eingesetzt und natürlich wird kein Dlookup verwendet. Na gut, für extrem vereinzelt im Formular Dsum oder Dmax möchte meine Hand nicht ins Feuer legen, das werde ich mal überprüfen und korrigieren. Solche Funktionen gibt es aber niemals in z.B. Abfragen.

Nochmal zu meiner Kernfrage, denn die Hoffnung stirbt zuletzt:

Irgendwie wär es doch traurig, wenn mann etwas mit ODBC-Verknüften MySQL-Tabellen hinbekommt, was mit verknüpften MDB-Datenbanken zu Problemen führt?

 

Hallo Horst,

ein Registryeintrag ist da nicht beteiligt. Es gibt ja auch keinen Eintrag "Don't crash" *Smilie

Ich vermute stark, dass da irgendwo ein Recordset nicht ordentlich zerstört wird.

 

In der Anlage eine kleine Zusammenfassung zum Fehler.

 

Folgendes könnte helfen:
Code:

Per Registry müsste das auch einstellbar sein.
Details: http://support.microsoft.com/?scid=k...5281&x=15&y=12

Ich würde allerdings zuerst versuchen, die Ursache zu finden.

Naja, die Sperrmechanismen von aktiven DBMS und dateibasierten DBMS könnten schon etwas unterschiedlich sein. *wink.gif*

 

1. Man kann den Wert von JET für die Anzahl an "Datenbanken" nicht ändern. Er ist laut Spezifikation auf 2048 festgesetzt. Übrigens ist - man kann es in einer Schleife testen - real schon früher Schluss, denn...
2. Eberhards Textdatei ist eigentlich alles, was es zum Thema zu sagen gibt. (Hier übrigens im Original: http://www.business-best-practice.de...beitrag_id=918 *wink.gif* )
Ansonsten der KB-Artikel zum Thema: http://support.microsoft.com/?scid=k...5272&x=10&y=18
3. @josef: Wie soll die Sperrzahl auf die MDB/LDB die Zahl der TableIDs beeinflussen? IMO hat das nichts miteinander zu tun.
Der Hinweis auf die Ursachenfindung ist aber sicher der Wichtigste.

Ciao, Sascha

 

\@Sascha: Ich war fälschlicherweise der Meinung, dass das zur gleichen Fehlermeldung führt. Da ich aber nirgends mehr ein Jet-BE mit etwas mehr Tabellen einsetze, fehlt mir definitiv die Erfahrung damit. *wink.gif*

zum von Eberhard zitierten Text:

Das kann ich nicht ganz glauben (außer man hat alles in einem Spaghetti-Code). Ist das wirklich so? Das Nothing-Setzen sollte VBA beim Verlassen der jeweiligen Prozedur eigentlich schon alleine hinbekommen. Ich hab nur in Erinnerung, dass es Probleme gibt, wenn man eine Recordset-Variable nur auf Nothing setzt, aber das Recordset zuvor nicht schließt.

 

Vielen Dank erst mal, für die vielen qualifizierten Antworten.

Es ist wohl so, wie ich es auch befürchtet habe, dass es wohl keinen einfachen Registry-Eintrag oder ähnliches gibt, Schade.

Somit kann ich wohl nur jede Menge Feinschliff betreiben, dann können vieleicht 1 bis 2 Formulare gleichzeitig mehr geöffnet werden. In den Formularen und auch Berichten sind halt teilweise auch viele Tabellen beteiligt. In VBA werden die Resourcen am Ende der Funktionen wieder freigegeben. Es gibt auch jede Menge Kombinationsfelder, hier werd ich mal überlegen erst bei Control_Enter() den controlsource zuzuweisen und beim verlassen wieder zu entfernen oder ähnliches.

Es liegt jedenfalls nicht daran, dass die Resourcen nicht wieder freigegeben werden, denn wenn ich Formulare wieder schließe, dann kann ich auch Andere wieder öffnen.

 

\@Josef: Das mit dem Recordset auf Nothing glaube ich auch kaum. Die Empfehlungen auf der Seite sind nicht alle astrein.

@Horst:

Und wenn du schon mal die DB (testweise?) auf MySQL portiert hast, warum macht ihr das nicht gleich generell?
Das lässt sich doch problemlos in ein Setup packen.
Eine so große DB ist IMHO eh nichts mehr für JET.

Wenn's unbedingt sein muss, kannst du aber auch zusätzlich weitere JET-Engines erzeugen (z.B. New PrivDBEngine). Die sollten dann jeweils wieder 2048 TableIDs schaffen.
Deren Recordsets dann halt für entspr. Code verwenden bzw. direkt Formularen zuweisen.
Nur ne Idee - getestet hab ich's nicht.

Ciao, Sascha

 

Hallo
@Horst Wessels
Hast Du schon einmal alle andern Üblichen masnahmen zur performance Verbeserung versucht ?


@josef und Sascha
ich mache zwar auch immer
„rs.Close“ und „Nothing“ und habe gedacht dass das gut (wichtig) sei
die DB soll man nicht umbedingt Closen hat einmal Jemand hier im Forum gesagt
weiss aber nicht mehr sicher wer (evtl. Anne)
lehrne aber gerne dazu *Smilie

 

rs.Close ist auch meiner Ansicht nach wichtig.
Je nach Anwendungsfall ist auch Nothing sinnvoll und ich schreib es auch gerne in den Code, damit die Objektvariable genau an dieser Stelle auf Nothing verweist und bei späterer Verwendung in der Prozedur ein Fehler ausgelöst wird.

Bei Prozeduren ist das Nothing-Setzen von Prozedur-Variablen sicher kein Fehler, aber aus VB(A)-Sicht nicht erforderlich, da das automatisch beim Verlassen der Prozedur passiert.

Das kommt darauf an, ob die DB-Instanz über OpenDatabase geöffnet wurde oder nur auf eine Currentdb-Instanz verweist.
Alles was man nicht selbst öffnet, muss man auch nicht schließen. *wink.gif*

 

In dem Sinne, wenn die Anwendung schnell genug ist, können gar keine Fehler mehr auftreten? Themenbezug?

Wenn die Objektvariable für CurrentDb steht, macht ein db.Close nicht nur keinen Sinn, sondern wäre in vielen Fällen höchst unangenehm (Schließen der Datenbank). Solcher Unsinn wird aber von Access ignoriert.

Hat man aber eine externe Datenbank in Verwendung, macht ein Close durchaus einen Sinn.

 

\@Sascha

Leider nicht so einfach, da dei Anwendung bei einigen Hundert Kunden im Einsatz ist. Da ist alles dabei, vom Einzel-PC bis zu 200 User Bunderweit über Terminal. Dort wird zur Zeit auch als Backend der MySQL Server eingesetzt. Der Einsatz des MySQL Server ist zukünftig nach Bedarf auch bei anderen Anwendern geplant.

Lizenzrechtlich bin ich mir nicht ganz sicher, aber ich meine, wenn wir den MySQL-Server generell mit ausliefern sind zumindest für uns als Softwarehaus Lizenzgebühren fällig. Da es aber alternativ angeboten wird, kann der Anwender selbst entscheiden ob er die kostenlose Version oder eine Kostenpflichtige Variante wählt.

Hast Du da ein Beispiel, denn man muss doch zumindest den MySQL-Server separat installieren? Teilweise haben wir auch Anwender, wo der Server auch gleichzeitig Arbeitsplatz ist. Ideal wäre ein Setup das fragt ob Server oder/und ODBC-Treiber installiert weren soll.

Bei 90% der Anwender macht das Access-Backend immer noch eine recht gute Figur. Erst bei vielen Benutzern und großen Datenmengen sehe ich die Hauptvorteile für MySQL. Bei schlechten Netzverbindungen sind die Access-Datenbank allerdings recht Fehler-Anfällig. Beim einlesen von Datanorm Daten z.B. 400.000 Artikel ist das Access-Backend sogar wesentlich schneller MDB = 45 min, MySQL = 6 Stunden.

Kannte ich noch nicht, muss ich bei Gelegenheit mal testen.
Man lernt doch immer noch dazu.

@Rudolf

Performance ist gar nicht das Problem, denn die ist sehr gut. Recordsetvariablen werden innerhalb der Funktionen erzeugt und da habe noch keinen Unterscheid feststellen können ob mit rs.close und set rs =Nothing oder ohne dem.