24
Access - Fehler 3048 Mehr Datenbanken können nicht geöffnet werden
Hallo zusammen,
MS Access aus der Office365 Suite überraschte mich heute morgen mit dieser Meldung und ich krieg es partout nicht gelöst.
Ein VBA Modul durchläuft ein Recordset (knapp 2000 Datensätze), um während des Durchlaufs diesen Befehl auszuführen:
CurrentDb.Execute "update statistik SET laletztertag=#" & Month(a) & "/" & Day(a) & "/" & Year(a) & "# where laid=" & mlaid & " and laletztertag<#" & Month(a) & "/" & Day(a) & "/" & Year(a) & "#", dbSeeChanges
(Der Befehl funktioniert so seit mehreren Jahren und auch auf mehreren Rechnern und ist jetzt nichts wirklich kompliziertes. Die Tabelle "statistik" liegt auf einem SQL Server Express und wird über ODBC angesprochen und hat 337 Datensätze)
Außer auf diesem einen PC ... hier passiert folgendes:
Nach dem 234.Durchlauf der Schleife kommt an dieser Stelle obengenannter Fehler, danach kann ich in Access keine einzige Tabelle mehr öffnen, es kommt nur noch "Unbekannter reservierter Fehler". Schließe ich Access, bleibt weiterhin ein Prozess "Microsoft Access" im Taskmanager offen.
Was ich bisher gemacht habe:
DB repariert
Office neu installiert
ODBC Treiber neu installiert
(Strohhalmversuch) CurrentDB.Execute durch ein set rs=CurrentDB.OpenRecordset ersetzt mit Edit/Update und Close/Nothing um sicher zu gehen, das in der Schleife das DB-Objekt auch wirklich wieder geschlossen wird.
Keine Besserung. Obwohl ich nicht mehr glaube das es an der Access Datei liegt, die läuft ja überall sonst, nur halt auf diesem Rechner nicht.
WindowsUpdates sind alle installiert.
Danke für Tipps.
MS Access aus der Office365 Suite überraschte mich heute morgen mit dieser Meldung und ich krieg es partout nicht gelöst.
Ein VBA Modul durchläuft ein Recordset (knapp 2000 Datensätze), um während des Durchlaufs diesen Befehl auszuführen:
CurrentDb.Execute "update statistik SET laletztertag=#" & Month(a) & "/" & Day(a) & "/" & Year(a) & "# where laid=" & mlaid & " and laletztertag<#" & Month(a) & "/" & Day(a) & "/" & Year(a) & "#", dbSeeChanges
(Der Befehl funktioniert so seit mehreren Jahren und auch auf mehreren Rechnern und ist jetzt nichts wirklich kompliziertes. Die Tabelle "statistik" liegt auf einem SQL Server Express und wird über ODBC angesprochen und hat 337 Datensätze)
Außer auf diesem einen PC ... hier passiert folgendes:
Nach dem 234.Durchlauf der Schleife kommt an dieser Stelle obengenannter Fehler, danach kann ich in Access keine einzige Tabelle mehr öffnen, es kommt nur noch "Unbekannter reservierter Fehler". Schließe ich Access, bleibt weiterhin ein Prozess "Microsoft Access" im Taskmanager offen.
Was ich bisher gemacht habe:
DB repariert
Office neu installiert
ODBC Treiber neu installiert
(Strohhalmversuch) CurrentDB.Execute durch ein set rs=CurrentDB.OpenRecordset ersetzt mit Edit/Update und Close/Nothing um sicher zu gehen, das in der Schleife das DB-Objekt auch wirklich wieder geschlossen wird.
Keine Besserung. Obwohl ich nicht mehr glaube das es an der Access Datei liegt, die läuft ja überall sonst, nur halt auf diesem Rechner nicht.
WindowsUpdates sind alle installiert.
Danke für Tipps.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1811289724
Url: https://administrator.de/forum/access-fehler-3048-mehr-datenbanken-koennen-nicht-geoeffnet-werden-1811289724.html
Ausgedruckt am: 09.01.2025 um 00:01 Uhr
24 Kommentare
Neuester Kommentar
Hi, ich hatte nach einem neuerlichen (jetzt aktuellem) Office365 Update auch einen "unerwarteten Fehler" beim Schließen von Formularen in Access.
Ich konnte die Fehler halbwegs lokalisieren indem die eingebetteten Makros durch eben nicht eingebettete Makros ersetzt wurden. Ebenfalls konnte ein RecordSet.Clone an der richtigen Stelle den "neuen "Fehler beim Schließen des Formulars verhindern. Viel Erfolg... vllt. ists ein Erfahrungsbericht bzw. Tipp der Dir weiterhilft.
(Ach und das Access einen Task im Hintergrund beschäftigt, wobei geschlossen... kenne ich auch; dieser mußte dann von Hand beendet werden, damit sich Access erneut öffnen läßt. Das ist nach dem Bereinigen der Fehler s.o. oder auch mehreren Neuinstallationen weniger geworden - ist fast gänzlich verschwunden, 1x noch vorgekommen.)
Ich konnte die Fehler halbwegs lokalisieren indem die eingebetteten Makros durch eben nicht eingebettete Makros ersetzt wurden. Ebenfalls konnte ein RecordSet.Clone an der richtigen Stelle den "neuen "Fehler beim Schließen des Formulars verhindern. Viel Erfolg... vllt. ists ein Erfahrungsbericht bzw. Tipp der Dir weiterhilft.
(Ach und das Access einen Task im Hintergrund beschäftigt, wobei geschlossen... kenne ich auch; dieser mußte dann von Hand beendet werden, damit sich Access erneut öffnen läßt. Das ist nach dem Bereinigen der Fehler s.o. oder auch mehreren Neuinstallationen weniger geworden - ist fast gänzlich verschwunden, 1x noch vorgekommen.)
same here, ebenfalls ein Recordset-Task, der seit Jahren läuft.
Office Build 16.0.14827.20028, ich tippe auf ein aktuelles Office-(nicht Windows!)-Update, hatte bisher nicht die Zeit, das zu ergründen.
Office Build 16.0.14827.20028, ich tippe auf ein aktuelles Office-(nicht Windows!)-Update, hatte bisher nicht die Zeit, das zu ergründen.
Aktuell so gelöst:
Office deinstalliert
alles in der regedit entfernt was mit dem Office 365 zu tun hatte
Rechnerneustart
Angemeldet bei Mikroweich365, neu heruntergeladen, installiert, fertig
Freuen wir uns auf die nächsten Bugs die als QualitätsUpdate verkleidet um die Ecke kommen.
Office deinstalliert
alles in der regedit entfernt was mit dem Office 365 zu tun hatte
Rechnerneustart
Angemeldet bei Mikroweich365, neu heruntergeladen, installiert, fertig
Freuen wir uns auf die nächsten Bugs die als QualitätsUpdate verkleidet um die Ecke kommen.
Welches Build hast du nach der Neuinstallation?
Nachtrag: Auf einem Zweitrechner, Build 16.0.14729.20224, hab ich die Probleme nicht. Hab hier die automatischen Updates erstmal gestoppt.
Nachtrag: Auf einem Zweitrechner, Build 16.0.14729.20224, hab ich die Probleme nicht. Hab hier die automatischen Updates erstmal gestoppt.
Morjn zusammen.
wäre zu schön gewesen, wenn die Neuinstallation die Lösung gewesen wäre . Seit heute morgen das selbe Problem wieder. Version 2201 Build 16.0.14827.20028.
Ich deinstalliere jetzt noch mal und deaktiviere die Updates.
wäre zu schön gewesen, wenn die Neuinstallation die Lösung gewesen wäre . Seit heute morgen das selbe Problem wieder. Version 2201 Build 16.0.14827.20028.
Ich deinstalliere jetzt noch mal und deaktiviere die Updates.
ich hatte gestern abend das gleiche Problem
Diesmal hat auch Neuinstallation nicht geholfen, rette mich aktuell mit einer parallel installierten Access2013Runtime.
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Access\Security\Trusted Locations\Location1]
Bei uns wurden beim Update die "TrustedLocations" einfach gelöscht.
Hierbei war das Problem das der Zugriff auf CurrentDB bei uns gescheitert ist also ein bisschen anderer Fall.
Prüft mal ob es bei euch daran liegt !
Bei uns wurden beim Update die "TrustedLocations" einfach gelöscht.
Hierbei war das Problem das der Zugriff auf CurrentDB bei uns gescheitert ist also ein bisschen anderer Fall.
Prüft mal ob es bei euch daran liegt !
Hallo zusammen
Habe eine Applikation mit 20 Rechnern seit fünf Jahren ohne Problem am laufen.
Seit ein paar Tagen haben immer mehr Rechner dieses Problem Access - Fehler 3048 .
Ich habe die Lösung mit Trust setting versucht. Leider kein Erfolg.
Danke für eine rasche Lösung. 10 Mitarbeiter stehen nun herum
Habe eine Applikation mit 20 Rechnern seit fünf Jahren ohne Problem am laufen.
Seit ein paar Tagen haben immer mehr Rechner dieses Problem Access - Fehler 3048 .
Ich habe die Lösung mit Trust setting versucht. Leider kein Erfolg.
Danke für eine rasche Lösung. 10 Mitarbeiter stehen nun herum
Ich habe seit dieser Woche genau das gleiche Problem, grundsätzlich mit dem Befehl CurrentDB. Eegal ob ich es einem Object zuweise oder direkt verwende, es funktionieren fast keine Makros mehr. Ich habe es zurzeit teilweise gelöst indem ich das CurrentDbC Modul verwende, die Datenbank geht dann zwar, aber ungeheuerlich langsam. Hat sonst niemand einen Workaround für CurrentDB?
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
Hi,
i) bei mir lag eine Access Instanz immer fest im Taskmanager, mußte die (den Prozess) manuell beenden, damit ich irgendeine Access db wieder öffnen konnte. Habe die Office365 Installation entfernt und neu Installiert. Irgendwann hat sich das System beruhigt. (Mußte aber in der db einige code Anpassungen machen, da eingebettete Makros nicht mehr funktioniert hatten (zwischenzeitlich), die wurden sicherheitshalber gegen außerhalb des forms angelgt.)
ii) Bei Kollegen kamen irre viele Fehlermeldungen (gleiche Datenbank) - mit denen ich nix anfangen konnte hoch. Hier wurde festgestellt, dass die Kollegen ein Office365 Update (innerhalb der Desktop App, z.B. Word-Konto-Updates) angestoßen hatten ohne alle Windows10 System Updates gemacht zu haben. Nach Installation aller Functionupdates und Systemupdates mit mehrfachen Neustarts hat sich Access beruhigt.
Gruß Nebellicht
(diverse Hilfen hier im Forum habe ich sicherheitshalber auch angewendet, wie Änderungen im TrustCenter und Systemreparaturen sfc /scannow und dism...)
i) bei mir lag eine Access Instanz immer fest im Taskmanager, mußte die (den Prozess) manuell beenden, damit ich irgendeine Access db wieder öffnen konnte. Habe die Office365 Installation entfernt und neu Installiert. Irgendwann hat sich das System beruhigt. (Mußte aber in der db einige code Anpassungen machen, da eingebettete Makros nicht mehr funktioniert hatten (zwischenzeitlich), die wurden sicherheitshalber gegen außerhalb des forms angelgt.)
ii) Bei Kollegen kamen irre viele Fehlermeldungen (gleiche Datenbank) - mit denen ich nix anfangen konnte hoch. Hier wurde festgestellt, dass die Kollegen ein Office365 Update (innerhalb der Desktop App, z.B. Word-Konto-Updates) angestoßen hatten ohne alle Windows10 System Updates gemacht zu haben. Nach Installation aller Functionupdates und Systemupdates mit mehrfachen Neustarts hat sich Access beruhigt.
Gruß Nebellicht
(diverse Hilfen hier im Forum habe ich sicherheitshalber auch angewendet, wie Änderungen im TrustCenter und Systemreparaturen sfc /scannow und dism...)
Habe das gleiche Problem seit einem Update von Office 365. So habe ich es größtenteils programmtechnisch lösen können. Seit dem Update muss die DB (in dem Fall kann auch rst.close ausgeführt werden) wieder geschlossen werden, dann tritt oben genannter Fehler nicht mehr auf.
In dem Beispiel wird die Datenbank mit Aufruf von "Test" 500 mal "geöffnet". Ist natürlich nur ein Beispiel.
Auf diese Art und Weise scheint man seine Programme umschreiben zu müssen
.....
Einen kleines Problem habe ich noch nicht gelöst. Es bleibt eine leere Access Instanz offen wenn man die DB geschlossen hat. Ich habe noch keine befriedigende Lösung dafür gefunden. Man kann beim Schließen des Hauptformulars die Access Prozesse killen. Geht - ist aber nicht so elegant. Vielleicht fällt euch ja was ein...
Ist aber wirklich ein Hammer was Microsoft sich da leistet, wenn das Update bei mir auf der Arbeit aufgespielt wird habe ich ein richtiges Problem.
greatmgm: Ersetze das CurrentDB wie hier dann müsste es wieder gehen.
In dem Beispiel wird die Datenbank mit Aufruf von "Test" 500 mal "geöffnet". Ist natürlich nur ein Beispiel.
Auf diese Art und Weise scheint man seine Programme umschreiben zu müssen
.....Einen kleines Problem habe ich noch nicht gelöst. Es bleibt eine leere Access Instanz offen wenn man die DB geschlossen hat. Ich habe noch keine befriedigende Lösung dafür gefunden. Man kann beim Schließen des Hauptformulars die Access Prozesse killen. Geht - ist aber nicht so elegant. Vielleicht fällt euch ja was ein...
Ist aber wirklich ein Hammer was Microsoft sich da leistet, wenn das Update bei mir auf der Arbeit aufgespielt wird habe ich ein richtiges Problem.
greatmgm: Ersetze das CurrentDB wie hier dann müsste es wieder gehen.
Option Compare Database
Option Explicit
Private dbc As dao.Database
Public Property Get CurrentDbC() As dao.Database
If (dbc Is Nothing) Then Set dbc = CurrentDb
Set CurrentDbC = dbc
End Property
Public Function test1() As Variant
Dim rst As dao.Recordset
Dim sql As String
sql = "SELECT [id] FROM Aktien"
Set rst = CurrentDbC.OpenRecordset(sql)
rst.MoveFirst
Do
rst.MoveNext
Loop Until rst.EOF
rst.MovePrevious
test1 = rst.Fields(0)
CurrentDbC.Close
Set dbc = Nothing
End Function
Public Sub test()
Dim a As Variant
Dim b As Integer
For b = 1 To 500
a = test1
Next b
MsgBox ("Fertig")
End Sub
Scheinbar viel Lärm um nichts - Gott sei Dank !
Das Verzeichnis muss im Trust Center lediglich als vertrauenswürdiger Speicherplatz hinterlegt werden.
Hoffentlich wars das ! Schwitz !
Die Aktion war aber lehrreich
Das Verzeichnis muss im Trust Center lediglich als vertrauenswürdiger Speicherplatz hinterlegt werden.
Hoffentlich wars das ! Schwitz !
Die Aktion war aber lehrreich
AccessFreak... man hab ich heute grossflächig bei der Access-DB, den Windows 10- und MS Office 365 Updates gesucht und rumgebastelt... bis zur Entdeckung deines heutigen Beitrags. Sooo genial! Danke vielmals 😊
Bei mir hat deine Info von heute, 15:50:56 Uhr
Aber auch bei mir bleibt derzeit immer noch eine leere Access Instanz offen, wenn man die DB schliesst. Hab ebenfalls noch keine befriedigende Lösung dafür gefunden.
Verwende zum Zwangsschliessen des resistenten Access-Tasks derzeit noch einen selbstgebastelten Access-Taskkill. Ansonsten schliess ich mich deinen Worten voll und ganz an:
Bei mir hat deine Info von heute, 15:50:56 Uhr
Das Verzeichnis (ev. inkl. Unterverzeichnis) muss im Trust Center lediglich als vertrauenswürdiger Speicherplatz hinterlegt werden
den vollen Erfolg gebracht. Nun kann ich die Access-DB endlich wieder öffnen, speichern, schliessen und komprimieren ohne lästige Fehlermeldungen.Aber auch bei mir bleibt derzeit immer noch eine leere Access Instanz offen, wenn man die DB schliesst. Hab ebenfalls noch keine befriedigende Lösung dafür gefunden.
Verwende zum Zwangsschliessen des resistenten Access-Tasks derzeit noch einen selbstgebastelten Access-Taskkill. Ansonsten schliess ich mich deinen Worten voll und ganz an:
Hoffentlich wars das ! Schwitz ! < und auch vielen Dank an Alle die hier helfen das Microsoftleben etwas Bug-freier zu gestallten.
... was die leere Instanz angeht, gibt im Trust Center doch mal die ganze Platte mit allen Unterverzeichnissen testweise frei. Ich vermute das Access noch irgendwo rumturnt und versucht in bei dir nicht freigegebenen Bereiche zu schreiben.
Zitat von @AccessFreak:
... was die leere Instanz angeht, gibt im Trust Center doch mal die ganze Platte mit allen Unterverzeichnissen testweise frei. Ich vermute das Access noch irgendwo rumturnt und versucht in bei dir nicht freigegebenen Bereiche zu schreiben.
... was die leere Instanz angeht, gibt im Trust Center doch mal die ganze Platte mit allen Unterverzeichnissen testweise frei. Ich vermute das Access noch irgendwo rumturnt und versucht in bei dir nicht freigegebenen Bereiche zu schreiben.
Bei mir bleibt die leere Instanz dadurch auch nicht mehr.
Hallo zusammen
habe jetzt alle 20 PC über das Trust Center nachgeführt. Access läuft ein bisschen länger aber dann taucht der Fehler wieder auf. Es ist wirklich schrecklich. Alle Arbeiten stehen. 10 Mitarbeiter nach Hause geschickt.
Was kann noch getan werden?
habe jetzt alle 20 PC über das Trust Center nachgeführt. Access läuft ein bisschen länger aber dann taucht der Fehler wieder auf. Es ist wirklich schrecklich. Alle Arbeiten stehen. 10 Mitarbeiter nach Hause geschickt.
Was kann noch getan werden?
Wie greifen die 20 PC denn auf die DB zu ? Hast du alle Platten komplett freigegeben ?
Ja habe ich. z.B. \\NASSide1\SISTSDB_CSL\
Auf meinem eigenen PC läuft alles bestens. Habe noch die alte Office Version
Auf meinem eigenen PC läuft alles bestens. Habe noch die alte Office Version
Greifst du über FAT Clients auf die DB zu ? Haben die noch eine eigene Platte ? Vielleicht testweise auf einem Rechner auch die mal freigeben.
Aktuell wird dieses Ei, was uns Microsoft gelegt hat, immer kurioser.
Ich habe jetzt Rechner da passiert nach dem Doppelklick auf eine mdb/accdb nichts mehr, bzw: es wird noch eine ldb/lccdb im selben Verzeichnis erstellt, aber kein Access geöffnet und jetzt kommts: es gibt auch keinen Prozess Access im Taskmanager, die Lockdatei ist aber gesperrt. Ich muss aktuell den Rechner neu starten um die Sperrung der Lockdatei aufzuheben um sie löschen zu können.
Nachtrag: das scheinst sich auch mit dem Trustcenter beheben zu lassen ... Haken rein bei Netzwerkpfade zulassen und den Speicherort mit anfügen.
Die CurrentDB umschreiben ist leider nicht umsetzbar, die VBA Module dürften zusammen an die 600.000 Zeilen Code haben ich teste an den Fehler3048-Rechnern mal die Sache mit dem Trustcenter.
Ich habe jetzt Rechner da passiert nach dem Doppelklick auf eine mdb/accdb nichts mehr, bzw: es wird noch eine ldb/lccdb im selben Verzeichnis erstellt, aber kein Access geöffnet und jetzt kommts: es gibt auch keinen Prozess Access im Taskmanager, die Lockdatei ist aber gesperrt. Ich muss aktuell den Rechner neu starten um die Sperrung der Lockdatei aufzuheben um sie löschen zu können.
Nachtrag: das scheinst sich auch mit dem Trustcenter beheben zu lassen ... Haken rein bei Netzwerkpfade zulassen und den Speicherort mit anfügen.
Die CurrentDB umschreiben ist leider nicht umsetzbar, die VBA Module dürften zusammen an die 600.000 Zeilen Code haben
ich teste an den Fehler3048-Rechnern mal die Sache mit dem Trustcenter.
@AccessFreak, kann ich hiermit bestätigen. Fehler 3048 lässt sich verhindern, wenn das Verzeichnis im TrustCenter hinzugefügt wird.
Hallo zusammen
Habe nun alle PC entsprechend eingerichtet. Habe Frontends und mehrere Backends
Wichtig ist auch, dass die NAS Lw nicht über die IP Adresse sondern über ihren Servernamen angesprochen werden.
Zudem müssen alle Verzeichnisse Frontend sowie Beckend im Trustcenter eingetragen werden.
Im Verknüpfungsmanager muss auch der Server angegeben werden und nicht der Lw-Buchstabe.
Seit ein paar Tagen läuft nun alles wieder soweit.
Ein Fehler der zwischendurch kommt ist:
Danke allen für euere Hilfe
Gruss
Thomas
Habe nun alle PC entsprechend eingerichtet. Habe Frontends und mehrere Backends
Wichtig ist auch, dass die NAS Lw nicht über die IP Adresse sondern über ihren Servernamen angesprochen werden.
Zudem müssen alle Verzeichnisse Frontend sowie Beckend im Trustcenter eingetragen werden.
Im Verknüpfungsmanager muss auch der Server angegeben werden und nicht der Lw-Buchstabe.
Seit ein paar Tagen läuft nun alles wieder soweit.
Ein Fehler der zwischendurch kommt ist:
Danke allen für euere Hilfe
Gruss
Thomas
Hi Thomas,
ja das kam bis vorige Woche auch manchmal bei mir, sogar wenn ich einfach nur eine Tabelle aufrufen wollte. Access zu machen und neu starten und es ging wieder. Seit diese Woche hat sich auch das Problem erledigt, dass Access nur im Hintergrund aufging und nur eine Lockdatei anlegte. Hoffen wir das Beste.
ja das kam bis vorige Woche auch manchmal bei mir, sogar wenn ich einfach nur eine Tabelle aufrufen wollte. Access zu machen und neu starten und es ging wieder. Seit diese Woche hat sich auch das Problem erledigt, dass Access nur im Hintergrund aufging und nur eine Lockdatei anlegte. Hoffen wir das Beste.
