Office: (Office 2010) Tabellenverknüpfungsmanager

Es gibt - mindestens im Acc2010 - ein Problem mit verknüpften Tabellen. Jüngere Versionen konnte ich diesbezüglich noch nicht testen.

Folgende Situation: ein FrontEnd ist mit einem BackEnd im Netzlaufwerk verbunden. Über den Tabellenverknüpfungsmanager soll - aufgrund eines Netzwerkproblems - das BackEnd gewechselt werden auf ein lokales BE. Das klappt für alle Tabellen, bis auf eine. Für diese kommt die Meldung, dass das (alte) Netzlaufwerk nicht gefunden werden könne und die Tabellen, die darunter in der Liste stehen, werden nicht neu verknüpft. Wenn ich diese eine Tabelle aus der Liste der neu zu verknüpfenden rausnehme, werden alle verknüpft.

Jetzt lösche ich diese Tabellenverknüpfung und erstelle sie neu über Externe Daten / Access ...
Die Verknüpfung wird neu angelegt aber es erscheint auch eine lokale Tabelle "Fehler beim Autospeichern von Objektnamen" mit Ursache "Das Objekt konnte nicht geöffnet werden".
Und tatsächlich lässt sich die neu verknüpfte Tabelle nicht öffnen. Es kommt beim Öffnen wieder die Fehlermeldung mit dem alten Netzwerkpfad, auf den nicht zugegriffen werden könne. Obwohl auch der ToolTipText an dem Verknüpfungssymbol den Pfad zu dem lokalen BE anzeigt.

Und jetzt kommts: eine Abfrage, die diese verknüpfte Datenquelle verwendet, funktioniert einwandfrei. Nur der direkte Zugriff auf die Tabelle ist nicht möglich.

Klingt seltsam, lässt sich aber auf mehreren Rechnern exakt so reproduzieren.

Jetzt habe ich gedacht, dass das daran liegen könnte, dass die fragliche Tabelle einen Umlaut im Tabellennamen hat. Das scheint auch damit zusammenzuhängen. Aber selbst wenn ich die Tabelle auf dem BE umbenenne und neu verknüpfen will, bleibt es bei dem beschriebenen Fehlverhalten.

:)

 

Hallo!

Wie ist das Verhalten, wenn du die Tabelle über VBA verknüpfst?

mfg
Josef

 

Moin Josef.
Es passiert exakt das Gleiche.
Die Tabelle wird verknüpft, zeigt im Navigationsfenster per ToolTipText den neuen Pfad, lässt sich aber nicht öffnen. Fehlermeldung bezieht sich auf den alten (nicht mehr vorhandenen) Netzwerkpfad.
Aber indirekt (über Abfragen) ist es kein Problem.

 

Hallo!

Vielleicht ist irgend etwas von der alten Verknüpfung in den sys-Tabellen hängen geblieben.
Verknüpfung löschen, Frontend komprimieren und dann neu verknüpfen hilft auch nicht?

mfg
Josef

 

Nee, leider auch nicht.
Das hatte ich als allererstes ausprobiert, als das auftrat.

Was besonders mysteriös ist, dass die neu verbundene Tabelle selbst mit einem anderen Namen im BE noch dies Verhalten aufweist.

 

Hast du probiert einen neue "frische" FE-Datei anzulegen und dort alles rein zu importieren?

 

Verknüpfungen werden in MSysObjects hinterlegt. Wie sieht es dort aus?

 

Nö. Ich komm ja an die Daten ran - über die Abfragen.

Sehe ich von hier aus nicht und komme auch erst am Donnerstag an diese Rechner dran.

Ich stelle das hier gleich mal nach. Allerdings habe ich hier (nur) Acc2016.

Aber - wie gesagt: dort war es auf jedem Rechner reproduzierbar.
Vielleicht mag es ja mal jemand mit Acc2010 nachstellen?

1. ein Backend mit (mindestens) einer Tabelle mit Umlauten auf ein gemapptes Netzlaufwerk legen und alle Tabellen mit dem FrontEnd verknüpfen
2. eine Kopie des BE auf die lokale Platte
3. das Netzlaufwerk trennen
4. mit dem Tabellenverknüpfungsmanager das FE mit dem lokalen BE verbinden

OK. Ich hab es mit Acc2016 probiert und es ist ganz genau so.
a) mit dem Verknüpfungsmanager bleibt er bei der Tabelle mit den Umlauten stehen mit der Fehlermeldung "... ist kein zulässiger Pfad". Hier frage ich mich doch bereits, was das soll. Der alte Pfad interessiert mich doch die Bohne. Ich will den neuen Pfad zuweisen.
b) alle anderen Tabellen (ohne Umlaut im Namen) werden ordentlich umgeswitcht.
c) wenn ich die fragliche Tabelle lösche - egal ob von Hand oder per VBA macht er das problemlos
d) wenn ich sie wieder hinzulinke - egal ob zu Fuß oder per Code, kann ich anschliessend nicht direkt drauf zugreifen.

Jetzt schaue ich mir mal nach den einzelnen Schritten jeweils die MSysObjects an und melde mich dann noch mal.

 

Also MSysObjects.

Da gibt es mit Type = 6 die Einträge für die verknüpften Tabellen.
Im Feld Database stehen die Pfade, im Feld Name und ForeignName stehen die Namen der verknüpften Tabellen.

Es gibt allerdings noch zwei weitere Datensätze mit Typ 6 und dem Zugriffspfad aufs Netzlaufwerk: Einer mit Name und ForeignName MSysComplexTypeVH und einer mit f_EDC255B57D5B48E6BA603BFB4844345E als ForeignName und f_2D207292D1534AAFB8563B40F0285AC4 als Name

Auffällig ist dabei zumal, dass fast alle verknüpften Tabellen im Feld Flags den Wert 2097152 stehen haben, lediglich die Verrknüpfung mit dem Umlaut im Namen hat hier 2359296. Und die beiden weiteren Datensätze haben unterschiedliche zehnstellige negative Werte.

Nach dem Ausführen (wie vorher beschrieben) von a) und b) bleiben die Datensätze für die Tabelle mit Umlaut und die beiden ominösen auf dem Netzwerkpfad im Feld Database.

Nach dem Löschen der Verknüpfung zu der Tabelle mit Umlaut sind diese drei Datensätze immer noch da.
Aber auch nach dem "Komprimieren und reparieren" bleibt immer noch der Datensatz von MSysComplexTypeVH - mit dem ollen Netzwerkpfad.

Und nach Ausführen von d) ist neben der neu verknüpften Tabelle mit Umlaut auch wieder ein Datensatz mit de GUID (?) drin erschienen - im Feld Name ist eine neue aber in ForeignName ist die selbe wie vor dem Löschen und neu verknüpfen.
Dieser und der Datensatz für die Verknüpfung haben beide im Feld Database den korrekten neuen Pfad.
Das Feld Flags hat nach dem neu Verknüpfen wieder den gleichen - abweichenden - Wert wie vor dem Löschen.

 

Ich hatte vor einiger Zeit mal etwas ähnliches.
http://www.ms-office-forum.net/forum...d.php?t=298994

Damals hatte ich nicht die Zeit der Sache weiter zu folgen.
Gruß
Tom

 

Ändert sich die Situation, wenn Du nach dem Löschen einen "definierten Zustand" herstellst, also das Frontend neu startest bzw. abgekürzt Application.RefreshDatabaseWindow anwendest?

In Anlehnung an den Vorbeitrag: Gibt es in den beteiligten Tabellen Felder wie Nachschlagefelder, Anlagefelder oder dgl., die auf weitere Tabellen (unsichbare Systemtabellen) verweisen könnten?

 

Ist das denn nicht nach dem "Komprimieren und Reparieren" kein "definierter Zustand"? Aber freilich, ich habe so ziemlich "alles" versucht.

Lieber Eberhard, dass Du mir so etwas zutraust ... *wink.gif*
Nein, so einen Dreck gibt es nicht.

Es gibt freilich Relationen, also drei Fremdschlüssel zu 1-Tabellen und eine am PK hängende n-Tabelle. Aber die haben alle anderen Tabellen schließlich auch und die werden ja korrekt umgehängt.

Hatte die fragliche Tabelle auch einen Umlaut im Namen?

 

Jetzt hab ich noch mal was anderes ausprobiert:

Eine Kopie des BE erstellt und in der Kopie die Tabelle mit dem Umlaut im Namen in eine Kopie - allerdings nicht stumpf kopiert sondern per SELECT INTO.
Diese Kopie dann mit den anderen vier Tabellen verknüpft.
Dann habe ich die Tabelle mit dem Umlaut-Namen gelöscht.
Dieses neue BE habe ich dann auf das Netzlaufwerk kopiert.

Dann habe ich ein neues FE erstellt und mit dem kopierten und geänderten BE auf dem Netzlaufwerk verknüpft.
Erste Überraschung: die beiden in #9 beschriebenen "seltsamen" Datensätze in der MSysObjects sind nicht mehr da.

Und - siehe da: das Umhängen des BE auf das lokale Laufwerk klappt problemlos und sozusagen "auf Mausklick".

Was lernen wir daraus:
Finger weg von Umlauten in Objektnamen !!!

 

OT: zu Objektnamen
Ich hatte mal in einem Formular eine Schaltfläche cmdÄndern genannt.
In Singapur, lief der gesamte VBA-Code nicht mehr, sobald das Formular nur geöffnet wurde (ohne diese Schaltfläche anzusprechen, dort war nicht mal Code hinterlegt).

Also, NIRGENDS Umlauten verwenden *idee

 

*top Daumen hoch für so viel Enthusiasmus.