Access-o-Mania

Hallo,
ich habe das gleiche Problem, welches Waldis hatte:
https://www.access-o-mania.de/forum/index.php?topic=21646.msg123946#msg123946

Mein Frontend startet nicht, wenn ich das Backend umbenenne bzw. verschiebe. Ich bekomme den Hinweis auf Komprimierung und dann den Startbildschirm, wo links die zuletzt geöffneten Datenbanken erscheinen. Ich hätte gedacht, das auch ohne Backend zumindestens das Startformular ohne Anbindung an einer Tabelle sichtbar wäre.

Habe auch keine Möglichkeit, mir Fehlermeldungen anzeigen zu lassen. Und bekomme auch keine Chance, den geänderten link einzugeben.

Hat jemand bitte eine Idee?!

Grüße

Hallo,
hast du dich schon mit dem Ersteller der DB-Anwendung in Verbindung gesetzt?
Wenn du es selbst bist, solltest du ja wissen was du programmiert hast  :) .

Erster Ansatz wäre der Start mit gedrückter (und festgehaltener) Shift-Taste.

Hallo Steffen,
das war wirklich witzig  ;D , aber leider nicht zielführend.
Geschrieben habe ich Sie und start mit gedrückter (und festgehaltener) Shift-Taste akzeptiert er in dem Fall nicht mehr. Ansonsten funktioniert das mit Shift..

Hallo,

Zitatdas war wirklich witzig

Das war nicht witzig gemeint.
Wenn die Shift-Taste nicht funktioniert (und eine AutoExec/Startformular startet), dann musst DU das so programmiert haben.

Man kann das aber wieder "wegprogrammieren" .....

Du kannst aber zunächst versuchen alle Objekte des FE in eine neue leere DB zu importieren.

Hallo,
wenn die Shifttaste nicht funktioniert, dann hat der Entwickler (also DU) diese Funktion in den Optionen abgeschaltet.
Zum Einschalten muss diese Funktion über VBA wieder aktiviert werden.
Da habe ich aber gerade keinen Code dazu parat.

Bei der Aufteilung einer DB in Backend und Frontend sollte eine automatischen Einbindungsfunktion der Backendtabellen realisiert werden.

Im Netz findet sich jede Menge Code dazu.

Das ist ja das kuriose. Wenn die Verbindung Backend / Frontend passt, kann ich mit Shift den Satrvorgang überwachen. Wenn der Pfad nicht stimmt, bewirkt das Shift drücken nichts. Die Datenbank wird nicht geöffnet.

Eine automatische Einbindungsfunktion der Backendtabellen habe ich integriert. Die wird aber gar nicht angesprochen.
Ich habe auf bereits ein neues Formular ohne Tabellen Anbindung erzeugt und dieses als Startformular benannt. Dieses brachte allerding auch nichts.

Die Objekte des FE in eine neue leere DB zu importieren wäre schon viel Arbeit. ::)

Hallo,

ZitatDie Objekte des FE in eine neue leere DB zu importieren wäre schon viel Arbeit

Ca 5 Tastenklicks sind viel Arbeit :D .

Neue DB erstellen und über
Externe Daten -> Access
alle Objekte importieren.

Ah , wieder ordentlich was dazugelernt :D

Also, ich habe die Datenbank kopiert. Die Größe ist von 300MB auf 20Mb geschrumpft, aber leider ist der Fehler immer noch da.
Ich kann weder mit Shift in denProzess eingreifen, noch öffnet er mir die Datenbank.

Iiest Du Deine privaten Nachrichten?

Das Problem haben wir außerhalb des Forums gelöst.
Es fehlte eine Prüfroutine der Tabellenverknüpfung,
welche bei Start der DB diese überwacht und gegebenenfalls
einen FileDialog startet, um eine neue Verknüpfung zu erstellen.

Leider wurde das Problem nicht gelöst, wie ich nach Rückfrage nun hörte.
Die Beispiel DB im Anhang ist auf das Wesentliche eingedampft.
Wie ich nun höre, dreht es sich beim TE um Access 2016, wie auch bei mir.
Allerdings benutzt er die 64bit Version und ich die 32bit Version.
Bei mir funktioniert alles, beim TE nicht.
Hier mal der Code in Modul 'mod_BackendVerknüpfung', der bei ihm einfach die FILEEXISTS Funktion ignoriert.
Auch Tests mit DIR statt FILEEXISTS werden ignoriert.
Public Function fncRelinkAccessTables() As Boolean
...
...
If (FileExists(BEPfad) = False) Then '>>>>>>>>>>> WIRD BEIM TE EINFACH IGNORIERT
    MsgBox "BackEnd-Datenbank nicht gefunden !@@" & _
           "Die BackEnd-Datenbank scheint umbenannt oder verschoben" & vbCrLf & _
           "worden zu sein." & vbCrLf & vbCrLf & _
           "Bitte suchen Sie die BackEnd-Datenbank und klicken Sie auf die" & vbCrLf & _
           "Schaltfläche 'Verknüpfen'." & vbCrLf & vbCrLf & _
           "Die Tabellen der BackEnd-Datenbank werden anschließend mit der" & vbCrLf & _
           "FrontEnd-Datenbank neu verknüpft.", _
           vbCritical, "Tabellenverknüpfung"
...
...
End Function       

Der Ablauf des DB Starts ist:
Aufruf des Makro AUTOEXEC.
Darin wird die Funktion 'fncRelinkAccessTables' aufgerufen.
Darin wird bei umbenanntem oder verschobenem BE ein Dialog aufgerufen, über welchen
man die BE neu verlinken kann.
Dann wird das Formular 'frmAdressen' aufgerufen.

Kann jemand, der Access 64bit benutzt diesen Effekt nachvollziehen und Tipps geben, was in 64bit zu ändern wäre?

Hallo derArb,


ich kann den beschriebenen Effekt nicht nachvollziehen.  Auf einer VM mit Win10-20H2 und Access2016-64bit erscheint nach Start der DB sofort die MsgBox bezgl. nicht gefundener Backen-Datenbank. Nach Klick auf OK wird der Filedialog geöffnet  mit Init-Verzeichnis Currentproject.Path.


Habe dann eine tblAdressen in einer accdb-Datei als Backend angelegt, um die Tabelle auch tatsächlich verknüpfen zu können. Auch hier läuft alles normal.


Sobald das Backend verknüpft wurde, wird die DB bei weiteren Neustarts normal gestartet.


Meine Vermutungen:


Sicherheitsoptionen nicht oder falsch eingestellt.
Windows-Userzugriffrechte auf das BE-Verzeichnis nicht ausreichend.

Was mir noch aufgefallen ist, ist der relativ lange Verzeichnispfad zum Backend, der möglicherweise Ursache für das Verhalten sein könnte.


Zudem: Die Selektion des Moduls ist im Makro überflüssig.


PS:   Wenn ich das anfänglich von martie01 beschriebene Problem interpretiere, so ist mir dieser Effekt auch schon mal untergekommen. Soll heißen, Access2016 (32bit) geht sofort ohne weitere Meldungen auf das Home-Fenster, wenn die BE-Datei nicht gefunden wird. Die DB wird nicht geöffnet.

Bei Access2029 hingegen kommt dagegen eine MsgBox mit dem Hinweis, dass das BE nicht gefunden werden kann und es wird anschließend der Navibereich angezeigt.

Eine ähnliche Prüfung der BE-Datei (wie hier im Beispiel) und Neuverlinkung hat dann Abhilfe geschaffen.

Vielen Dank an alle Beteiligten schon einmal.
Ich werde am WE das mit den Rechten des be prüfen.
Und Anderes ausprobieren...

Hallo!

Zitat von: undefined

Code [Auswählen] Erweitern

Public Function fncRelinkAccessTables() As Boolean
   ...
   ...
   If (FileExists(BEPfad) = False) Then '>>>>>>>>>>> WIRD BEIM TE EINFACH IGNORIERT
      ...

Ist in den "..." eine On Error Resume next enthalten?

Eventuell hilft diese Änderung:
Public Function fncRelinkAccessTables() As Boolean
   ...
   dim BeExists as boolean
   BeExists = FileExists(BEPfad) ' bleibt false, falls durch Fehlerbehandlung übergangen
   If not BeExists Then
      ...mfg
Josef

Hallo,
@franz, DF6GL: Danke für den Tip im Autoexec Makro.
@Josef P.: Es funktioniert ja auch nicht die DIR-Funktion.
Ich bin gespannt, was die Lösung sein wird.

Hallo Josef ,
ich bin mir nicht ganz sicher, wo ich den CodeSchnipsel einfügen kann.

Interassanter Weise: wenn ich die Datenbank mit Shift öffne, dann das BE umbenenne, greift die Funktion und fragt nach einem neuem Pfad.
Ändere ich das Be bevor ich die Datenbank öffne, stürzt das FE ab?
Die Rechtevergabe ist i.O.

Ich vermute mal, das der falsche Pfad nicht richtig abgefangen wird. ::)

An der Stelle?

'Bei unauffindbaren UNC-Pfaden eine nicht existierende Dummy DB angeben.
   If Left(BEPfad, 1) = "\" Then BEPfad = "c:\blablaXXX.accdb"
  ' anschließend prüfen ob aktueller pfad der verknüpfung auch im windows
  ' verzeichnis gefunden wird
 
  Dim BeExists As Boolean
   BeExists = FileExists(BEPfad) ' bleibt false, falls durch Fehlerbehandlung übergangen
   If Not BeExists Then
   
   
  If (FileExists(BEPfad) = False) Then
    MsgBox "BackEnd-Datenbank nicht gefunden !@@" & _

Hallo,
meine Vermutung ist, dass die Datenbank mit dem fehlenden Backend gar nicht startet/starten kann.

Deaktiviere mal AutoExec-Makro und auch ein (eventuelles) Startformular.

Danach sollte die DB normalerweise auch bei fehlendem BE ganz normal starten.

Tut sie das nicht, dann ist jede Programmierung (zunächst) vergebens.

Hallo Steffen,
das habe ich ja auch schon ausprobiert.
Anderes leere Formular ohne BE Anbindung und ohne AutoExec...hat nix geholfen.
Bin auch ziemlich ratlos.
Habe auch mal alle Module ausgeklammert.

Hallo,
ich weiß nicht ob wir uns richtig verstanden haben:
Aber wenn die DB ohne jeden Code nicht startet, dann kann der Fehler nicht im Code liegen und auch nicht mit Code korrigiert werden.

Es stellt sich jetzt halt die Frage, warum das (nur) bei dir so ist.
Kannst du das (abgespeckte) FE hochladen?

Hallo,

soweit ich das verstanden habe,

startete die DB ursprünglich nicht, wenn das BE nicht existierte. Access selber startet, läd die DB aber nicht  und zeigt gleich das Home-Fenster an. Auch mit Shift-Taste kommt man nicht in die DB (zum Navibereich).


(Diesen Effekt hatte ich selber vor einiger Zeit bei A2016 auch beobachtet. Erst als die BE-Datei in das erwartete Verzeichnis kopiert wurde, konnte man zum Navibereich gelangen und dort über den Tabellenverknüpfungsmanager eine anderes BE auswählen und verknüpfen.)

Bei A2019 trat dieser Effekt mit derselben DB und derselben OS-Umgebung nicht auf. Dort kam, wie ich es vorher schon beschrieben habe, ein Hinweis auf fehlende BE-Datei und die DB wurde anschließend geöffnet (Navibereich).


Nach Einbau des Codes für einen  Relink wird dieser ausgeführt, bleibt aber beim Prüfen der BE-Datei hängen, bzw. die Dir()-Funktion und in Folge die Neuverknüpfung arbeiten nicht.

Dies konnte ich hier allerdings nicht nachvollziehen. Bei mir lief der Verlinkungs-Code ohne Probleme durch, soll heißen die DIR()-Funktion arbeitet bei mir korrekt. Einziger Unterschied ist, dass der BE-Pfad wesentlich kürzer in  meiner Test-DB ist als im Original. (Und natürlich mit eingestellten Sicherheitsoptionen.)

Ich folgere daraus, dass der elend lange BE-Originalpfad nicht oder nicht richtig von Dir() oder Fileexists verarbeitet werden kann.

Ein Test mit einem ähnlich langen Pfad konnte ich durchführen.

Ich kann mich auch dunkel erinnern, dass es vor einiger Zeit in dieser Beziehung schon ähnliche Probleme gab mit langen Pfaden.

Hallo,

ZitatNach Einbau des Codes für einen  Relink wird dieser ausgeführt, bleibt aber beim Prüfen der BE-Datei hängen, bzw. die Dir()-Funktion und in Folge die Neuverknüpfung arbeiten nicht.

Das ist nach meiner Meinung nur "eingebildet".
Nach meiner Meinung/Vermutung startet überhaupt kein Code.

Hallo,

ZitatDas ist nach meiner Meinung nur "eingebildet".

???????????????????????????

Hallo,

ich habe mal eine VorgängerVersion der Datenbank hochgeladen, wo dieser Fehler existent ist.
https://drive.google.com/drive/folders/12wL3FHbgseCDCE4cClqsRTloZiV2dKes?usp=sharing

Wenn das BE unter : "C:\Neuer Ordner\kopy_dataschalt_281120_be.accdb" liegt, ist die Welt i.O.

Benennt man sie um, scheitert es.
Ich habe auch mal in eine neue DB die Tabellen reinkopiert und so wie oben benannt . Dann startet sie auch nicht.

Wenn ich diese Funktion nicht so dringend bräuchte, wäre mir das ja auch egal.

Wäre super, wenn einer eine Lösung findet.

Gruss Martin

Hallo martie01,
ich glaube nicht, dass Du jemanden animieren kannst, sich durch Deine DB durchzuwurschteln,
was wir beide schon per Teamviewer gemacht hatten.

Wenn meine Version im Anhang bei Dir nicht funktioniert und bei allen Beteiligten doch (wenn sie diese herunterladen),
dann liegts nicht an 32bit oder 64bit.
Bei mir und vielen anderen funktioniert es seit vielen Jahren mit Accessversionen 2007, 2010, 2013 und jetzt 2016.

Du könntest mit Franz, DF6GL noch abgleichen, welches Update der Accessversion 2016 ihr beide genau benutzt.
Könnte es ein Bug sein?
@DFGL: Ich benutze auch sehr sehr lange Pfadnamen und hatte bisher keine Probleme.

@steffen0815 zu #17: Lad Dir einfach meine Beispiel DB und debug sie. Es wird natürlich der Code abgearbeitet.
Nur wird bei martie01 aus unerklärlichen Gründen nicht erkannt, warum NUR !!! bei ihm die Routine
"Backend nicht gefunden, starte einen FileDialog" ignoriert wird. Backend_2021_Jan_BE_Check_AufrufInAutoexec_FE_BE.zip

Hallo,


der Start der Db funktioniert bei mir ohne Probleme. Auch mit dem nachgebauten langen Pfadnamen wird ein fehlendes BE erkannt und der Filedialog geöffnet.

VM Win10 20H2 und Access-Version lt. Bild

Hallo!

Bei mir funktioniert die Datei aus #23 ebenso (zumindest wenn ich die Fehlerbehandlung aktiviere).

Ein Schuss ins Blaue: vielleicht hat Martin auch die Fehlerbehandlung auf "Bei jedem Fehler unterbrechen" eingestellt.

Auszug aus der Datei aus Beitrag #23:
Function FileExists(Path As String) As Boolean
    Const NotFile = vbDirectory Or vbVolume
    On Error Resume Next
    FileExists = (GetAttr(Path) And NotFile) = 0
    On Error GoTo 0
End Function
Dieser Code scheitert, wenn "bei jedem Fehler unterbrechen" aktiviert ist. ;-)
Theoretische Abhilfe:
Application.SetOption "Error Trapping", 2
vor die Zeile mit
FileExists = (GetAttr(Path) And NotFile) = 0schreiben, damit On error resume next wirkt. (Es wird dadurch auf "bei nicht verarbeiteten Fehlern" umgeschalten.)


Allerdings steht weiter oben im Thread, dass auch VBA.Dir(..) nicht funktionierte.
Zum Testen:
Function FileExists(ByVal FilePath As String) As Boolean

On Error Resume Next ' VBA.Dir bringt Fehler, wenn Zugriffsrechte fehlen.
   FileExists = (VBA.Len(VBA.Dir(FilePath, vbReadOnly Or vbHidden Or vbSystem)) > 0)
   
   If Not FileExists Then
      Debug.Print "Datei '" & FilePath & "' ist nicht vorhanden"
      Stop ' <-- hier sollte Code in der accdb stehen bleiben, wenn der BE-Pfad nicht stimmt.
   End If

End FunctionFalls der Code an der oben markierten Stelle (oder direkt bei der Zeile FileExits = (VBA.Len(...)) bei fehlendem BE nicht stehen bleibt, wird der Fehler nicht an dieser Dateiprüfung liegen.


Anm.:
Die Datei von Martin schaute ich mir nur kurz an, da ich dort keine BE-Prüfung vor dem Formularöffnen fand.
Es wird in dieser Datei gleich ein Formular geöffnet, in dem Daten aus dem verknüpften BE über DLookup (Funktion im Steuerelementinhalt) benötigt werden. ... Dieses Lookup schlägt natürlich fehl, wenn die Verknüpfung nicht stimmt => so wie in der anderen Datei die Prüfung durchführen, bevor das eigentliche Startformular geöffnet wird.

mfg
Josef

Hallo  und Danke erst einmal allen Beteiligten.
Ich werde das alles mal durchgehen und prüfen.

Grüße Martin

Hallo,
das FE von Martin aus #22 lässt sich an keinem meiner Rechner ohne Backend starten. Auch das Abschalten des Startformulars ändern nichts an diesem Verhalten.

Ursache dafür ist die "USysRibbons" welche auf das nicht vorhandene BE zeigt.

Aus diesem Grund wird in dieser Version auch keinerlei Code aufgerufen.
Ein Neueinbinden des BE kann so nmM gar nicht funktionieren.

Hallo,


ich glaube, wir haben es hier mit ein paar unglücklich zusammenfallenden Effekten zu tun.

1) die USysRibbons-Tabelle (bzw. Link)  als Systemtabelle will Access (neben anderen Sys-Tabellen) als erstes laden, bzw. auswerten, bevor irgendwelche weiteren Aktionen durchgeführt werden. (Das gilt nicht nur für die Systemtabellen, auch bei verlinken Text(Csv)dateien   und xls-Dateien tritt dies auf).  Das ergibt folglich wegen des fehlenden BEs (oder der fehlenden Dateien) einen Laufzeitfehler, der

  a) bei Access 2016 keine (zumindest keine sichtbare oder den Ablauf unterbrechende) Fehlermeldung produziert und dazu führt, dass nicht das DB-Fenster (Navibereich), sondern das Access-Start-Fenster geöffnet wird. Soll heißen, der Ladevorgang der DB wird abgebrochen. Daran ändert auch die Shift-Taste nichts. (Dieser Effekt war m. E. das ursprüngliche Problem.)  Es ist lediglich manchmal ein kurzes "Aufblitzen" des DB-Fensters zu erkennen. (Hier schlägt wohl wieder "It's not a bug, it's a feature" zu.)

  b) bei Access 2019 eine diesbezügliche Fehlermeldung ("Datei nicht gefunden") ausgibt, die "weggeklickt" werden kann und Access anschließend trotz der Fehlersituation die Db (Navibereich) läd und es möglich ist an der DB weiter zu arbeiten.


Insofern ist es grundsätzlich nicht zu empfehlen, eine USys- oder MSys-Tabelle als Link auf eine BE-Datei im FE anzulegen.


2)  Die Ursache für die Fehlfunktion von Dir oder FileExists könnte m. E. zum einen an den nicht ausreichend eingestellten Sicherheitsoptionen und/oder an den von Josef angesprochenen VBA-Optionen liegen. Hierzu habe ich keine Test gemacht. Die Vermutung eines zu langen Dateinamens hat sich hier nicht bestätigt.

Hallo,
@martie01: Beantworte mir und uns doch nochmal,
ob meine Beispiel DB aus #23 bei Dir funktioniert.
Sie funktioniert bei Franz, DF6GL und Josef P.
Steffen0815 hat dazu noch keinen Kommentar abgegeben.
Wäre schön, wenn er es auch kurz bei sich testen würde.

@Alle: In dieser Beispiel DB gibt es keine Ribbons und keine "USysRibbons".

Wenn es bei allen funktioniert und bei Dir nicht, dann steh ich auf dem Schlauch,
denn bei dem von Josef P. angeregten Versuch, die Fehlerbehandlung per VBA
auf den richtigen Wert zu stellen, bringt in meiner Beispiel DB auch nix, weil sie
einfach richtig eingestellt ist und bei falscher Einstellung sofort in den Debugger springt
und die gefundene VBA-Zeile farblich unterlegt anzeigt.

@derArb:
Deine Datenbank funktioniert (natürlich)  :).

Zitat von: Steffen #18Aber wenn die DB ohne jeden Code nicht startet, dann kann der Fehler nicht im Code liegen und auch nicht mit Code korrigiert werden.

Ich hatte deine DB gar nicht erst getestet, da ich ja der Meinung bin, dass es nicht am Code sondern an der Datenbank liegt.
Dieses hat sich mMn auch durch #27 bestätigt.

Deine DB wird sicher auch bei Martin funktionieren.

Hallo, an Alle,
das werde ich gerne zeitnah testen.
Habe erst einmal gefrustet das zur Seite gelegt.
Werde aber mit den neuen Infos wieder ans Werk gehen.

Danke erst einmal an Alle..

Hallo, an Alle,
so, ich habe die Test Datenbank runtergeladen, welche funktioniert und habe daraufhin mein BE und FE in eine komplett neue Datenbank importiert und seitdem funktioniert die Datenbank.

Der Fehler lag , so wie steffen0815 mir ja auch schon den Tip gab, an:
Ursache dafür ist die "USysRibbons" welche auf das nicht vorhandene BE zeigt.

Und wenn ich mich dunkel daran erinnere, habe ich vor langer Zeit das mal versucht, einzubauen und wieder verworfen.
Und das waren wahrscheinlich die Reste, die übrigblieben. ::)

Im Nachherein erscheint es ja auch logisch....

Von daher nochmals vielen Dank an Alle; Ihr habt mir sehr geholfen.

Gruss Martin