Januar 19, 2021, 05:47:32

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Access 2016 mit Back und Frontend startet nicht

Begonnen von martie01, Dezember 29, 2020, 10:08:52

⏪ vorheriges - nächstes ⏩

martie01

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 !@@" & _

steffen0815

Januar 08, 2021, 20:01:33 #16 Letzte Bearbeitung: Januar 08, 2021, 20:25:14 von steffen0815
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.
Gruß Steffen

martie01

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.

steffen0815

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?
Gruß Steffen

DF6GL

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.








steffen0815

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.
Gruß Steffen


martie01

Januar 09, 2021, 11:21:43 #22 Letzte Bearbeitung: Januar 09, 2021, 12:07:56 von martie01
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

derArb

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. Sie dürfen in diesem Board keine Dateianhänge sehen.

DF6GL

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

Josef P.

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 Function
Falls 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




martie01

Januar 10, 2021, 09:03:34 #26 Letzte Bearbeitung: Januar 16, 2021, 17:34:44 von martie01
Hallo  und Danke erst einmal allen Beteiligten.
Ich werde das alles mal durchgehen und prüfen.

Grüße Martin

steffen0815

Januar 11, 2021, 08:05:33 #27 Letzte Bearbeitung: Januar 11, 2021, 08:23:38 von steffen0815
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.
Gruß Steffen

DF6GL

Januar 11, 2021, 10:25:37 #28 Letzte Bearbeitung: Januar 11, 2021, 13:23:36 von DF6GL
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.










derArb

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.