Es können keinen weiteren Datenbanken geöffnet werden

06/08/2008 - 18:27 von micha2 | Report spam
Habe Access 2003 SP 3 im Einsatz und eine Anwendung die ausschließließlich
aus Registerelementen besteht. Im wesentlichen werden die Daten in drei
(Haupt)Tabellen gehalten, wobeidie größte derzeit ca. 10.000 DS , die beiden
kleineren jeweil ca. 800 DS haben haben. Seit kurzem erhalte ich, wenn
mehrere Berichte gleichzeitig aufrufe, die Fehlermeldung "Es können keinen
weiteren Datenbanken geöffnet werden". Die Daten sind in einer Backend mdb.
Eine zusàtzlich mdb liefert über Verknüpfungen noch weitere Informationen.
Im letzten ACCES_Actuell kam zufàlligerweise eine Abhilfe, DLookupEx() statt
DLookup. Hat das Problem nicht gelöst. Wer kann mir bitte noch Hilfestellung
geben?
Herzlichen Dank im Voraus
 

Lesen sie die antworten

#1 Michel Fouquet
06/08/2008 - 19:16 | Warnen spam
Hallo,

micha2 schrieb:
Habe Access 2003 SP 3 im Einsatz und eine Anwendung die ausschließließlich
aus Registerelementen besteht. Im wesentlichen werden die Daten in drei
(Haupt)Tabellen gehalten, wobeidie größte derzeit ca. 10.000 DS , die beiden
kleineren jeweil ca. 800 DS haben haben. Seit kurzem erhalte ich, wenn
mehrere Berichte gleichzeitig aufrufe, die Fehlermeldung "Es können keinen
weiteren Datenbanken geöffnet werden". Die Daten sind in einer Backend mdb.
Eine zusàtzlich mdb liefert über Verknüpfungen noch weitere Informationen.



die Meldung zum Fehler 3048 ist leider irreführend. Dabei geht es nicht
um Datenbanken als solche, sondern um Instanzen (Objektvariable).

Immer darauf achten, dass z.B. Recordsets nicht nur per rst.close
geschlossen werden, sondern die Objektreferenz explizit per Set rst =
Nothing vernichtet wird.

Statt mehrfacher CurrentDB-Aufruf Mike Kaplans Vorschlag zur Verwendung
einer Public Property CurrentDbc folgen:

Private m_DaoDB As DAO.Database

Public Property Get CurrentDbc() As DAO.Database
If (m_DaoDB Is Nothing) Then
Set m_DaoDB = CurrentDb
End If
Set CurrentDbc = m_DaoDB
End Property

und dann halt CurrentDbc statt CurrentDB verwenden.

Das "ordentliche" Schließen und Vernichten der Objektvariablen wird
allerdings durch ein zweites Problem überlagert - die Anzahl der
verfügbaren "table handles". Dazu

1. schau mal hier:
http://support.microsoft.com/defaul...US;Q165272

Da geht es zwar um Jet 3.5, aber die Hinweise auf die sog. TableID
(table handle) sind entscheidend.

2. Große Fresser von Handles sind die Domànenfunktionen, zumal in
Verbindung mit dem Befüllen von Endlosformularen oder Berichten.

3. Große Fresser von Handles sind verschachtelte Abfragen (Subselects).

4. Große Fresser von Handles sind UNION-Abfragen.

5. Große Fresser von Handles sind Berichte mit zahlreichen
Unterberichten (und vielen Berechnungen im Format-Ereignis).

6. Große Fresser von Handles sind Formulare mit Kombi- und/oder
Listenfeldern, insbesondere kaskadierende Kombifelder (Inhalt des
zweiten beruht auf Vorauswahl im ersten), und mehreren gebundenen
Unterformularen. Alle nicht benötigten Formulare schließen.

7. Große Fresser von Handles sind mehrfach aufgerufene Formularfilter
ohne Schließen des Formulars.

8. Große Fresser von Handles sind rekursive Aufrufe oder Schleifen.

9. Soweit ich mich dunkel erinnere, erzeugen auch Indexe TableIDs und
machen damit den Speicher zu. D.h. der Aufruf *einer* Tabelle mit 5
Indexen verbràt von vornherein schon mal 6 Handles. Durch eine
Domànenfunktion gejagt, da gehen schon massig Handles weg.

10. Große Fresser von Handles sind replizierte Datenbanken.

11. In manchen Fàllen tauchte das Problem erst nach der FE/BE-Aufteilung
auf. Eine *eingebundene* Tabelle verbraucht bereits mindestens 2 table
handles.

<zitat>
I think the splitting of the database is what threw the TableIDs over
the limit. It is pretty rare to see this error in Jet 4.0, but many
times linked tables are involved since they use at least two TableIDs
for each link.

Michael Noto
Microsoft Support
</zitat>

Das ist, was ich im Laufe der Zeit zu dem Thema so zusammengesammelt
habe.

Ähnliche fragen