Office: (Office 2010) Nicht erkennbares Datenbankformat

Hallo,

hast du auch mal in alles Tabellen die Schlüssel- und Primarschlüssel auf Vollständigkeit geprüft? Sind alle Beziehungen noch vorhanden?

Diese wichtigen Eigenschaften gehen teilweise auch verloren und könnten das Verhalten der Anwendung verändern.

HTH

 

Wir hatten vor längerem mal ein ähnliches Problem. Damals hatten wir verschiedene OS auf den lokalen User PC's. Das Problem entstand damals (offensichtlich) durch das unterschiedliche Rechtemanagement von Win7 und WinXP. ServerOS war damals Windows 2008 R2 Server. Bei der Verwaltung der lokalen ldb's und der Server ldb kam es zu Problemen, die sich nicht mehr nachvollziehen ließen. Erst nach dem Umstieg aller UserPC's auf Win7 trat das Problem nicht mehr auf.
Ob das Problem nun am Server lag oder im Zusammenspiel Server - XP User entstand, kann ich leider nicht mehr sagen.
An den Backend Dateien haben wir jedenfalls nichts ändern müssen und sie laufen heute noch problemlos.

 

\@stendate
Die Beziehungen sind alle noch vorhanden und die Datenbank läuft im Einzelbetrieb auch absolut einwandfrei.

@tomlei
Hallo Tom
Deine Rückmeldung ist eine ganz heisse Spur. Vielen Dank dafür. Ich werde diese Möglichkeit mit dem Server- und Netzwerkspezialisten besprechen und hoffe, dass ich damit einen Durchbruch zur Lösung der Probleme erziele.

Ich melde mich wieder in den nächsten Tagen.

Franz

 

Hallo Franz,

zum Tipp von Tom (der in die richtige Richtung weist, da in einer AD mit verschiedenen Clients unterschiedliche Handles der Freigaben greifen, werden vermutlich gar nicht genutzte Datensätze in den Tabellen als exclussiv geöffnet geflaggt und gesperrt. Dieser unschöne Nebeneffekt führt zu der verwirrenden Fehlermeldung!) möchte ich noch folgendes anmerken:
Windows XP hat in Produktivumgebungen nichts!!! mehr zu suchen. Ein End Of Life-Betriebssystem von Microsoft stellt ein Sicherheitsrisiko dar, das kein Virenscanner und keine Firewall auffangen kann.
Mit der richtigen Strategie ist auch ein älterer PC in maximal 2 Stunden mit Standardsoftware und zumindest Windows 7 versorgt. Reseller-Lizenzen gibt es schon um knapp 30,- € in der Bucht. Selbst ein mageres Budget kann also kein Hinderungsgrund darstellen, nicht auf sicherere Betriebssysteme umzusteigen - zumal ich unterstelle, dass die bisherige Fehlersuche, der Stillstand und die Datenverluste bereits einiges an Kosten verursacht haben.

Ich vermute stark, dass nach dem Umstellen aller XP-Rechner auf Windows 7 (sicherheitshalber empfehle ich bei älterer Hardware die 32bit-Version) die Probleme der Vergangenheit angehören.

 

Hallo Norbert

Danke für Deinen guten Input, mit dem ich - was XP betrifft - voll und ganz einverstanden bin. Ich habe noch folgende Verständnisfrage:
Gibt es die erwähnten Handle-Probleme bereits, wenn ein Win-XP-PC - ohne die Access-Datenbank darauf zu öffnen - im Netzwerk arbeitet (doc, xls, pdf etc.) oder kommen die Probleme erst, wenn der XP-PC gleichzeitig mit anderen PC's mit Win7/8.1 mit der Datenbank arbeitet?

Danke und Gruss
Franz

 

Hallo Franz,

das reine "vorhanden sein" im Netzwerk darf das Problem nicht auslösen. Erst, wenn die Datei tatsächlich vom Client "angefasst" wird, geht der Spuk los.

Zwei weitere Punkte möchte ich noch hinterfragen:
Arbeitet Ihr mit einem zentralen Loginscript? Also jeder Rechner hat das selbe (Netz-)Laufwerk für die AccessDB oder sind die Tabellen durch den UNC-Pfad verknüpft?
Warum hievt Ihr das Backend nicht an beiden Standorten auf das neue Format?

 

Hallo Norbert

Wir werden heute Vormittag nur mit Win7-PC's arbeiten und sehen, wie sich die Anwendung verhält.

Wir haben ein zentrales Loginscript. Die Tabellen sind jedoch über UNC-Pfad verknpüft.

Die Datenbank wurde seinerzeit von einem ehemaligen Mitarbeiter erstellt und hat viele konzeptionelle und handwerkliche Fehler (Beziehungen, Objektbezeichnungen, Indizierung, ErrorHandling, VBA-Spaghetti-Code etc. etc.). Wir arbeiten momentan mit Hochdruck an einer neuen Datenbank und hoffen, diese anfangs 2015 in Betrieb nehmen zu können.

Gruss
Franz

 

Hallo zusammen

Die Probleme gehen weiter ....
Montag: Arbeit nur mit Win8 PC's -> keine Probleme oder Fehler
Dienstag: Arbeit nur mit Win7 PC's oder Kombination Win7 + Win8 PC's -> 3 x unbekanntes Datenbankformat. Die XP-PC's waren nicht eingeschaltet.

Wir konzentrieren uns nun auf das Serverkommunikationssystem SMB. Der Win Server 2012 R2 ist auf SMB3 eingestellt. Wir überlegen uns nun die Änderung auf SMB2. Zudem stellt sich die Frage, wie das "Opportunistic Locking" auf Server und PC eingestellt werden soll.

Was mich sehr erstaunt ist die Tatsache, dass der Fehler "unbekanntes Datenbankformat" auch auftritt, wenn nur Windows 7 PC's (32+ 64-Bit) eingeschaltet sind. Der Fehler tritt sporadisch (ca. alle 2 Std.) und ohne erkennbares Schema ab.

Hat jemand von Euch Erfahrungen damit und kann mir einen Tipp geben?

Danke Euch im Voraus bestens.
Franz

 

Hi,

ich durchlebte diese "Hölle" vor ein paar Jahren auch. Das Problem ist, dass es z.B. auch ein defekter Switch oder eine defekte Netzwerkkarte sein könnte...

Der direkte Weg zu Lösung heißt ODBC + SQL Server, oder ggf. Terminal-Server + Backend auf C:\ (ohne Netzlaufwerk).

 

Hallo stendate

Die Erfahrung mit defekten Routers und Switches hatte ich schon 2x. Immer war die Access-Datenbank schuld bis ich das Gegenteil beweisen konnte.

Im vorliegenden Fall habe ich nach dem Ausschlussverfahren versucht, den Fehler einzugrenzen. Nachdem gestern mit Win8 alles OK war, haben wir heute bei jedem Fehler den Win7-PC, der die Fehlermeldung gebracht hat, ausgeschaltet. Der Fehler kommt jedoch bereits bei 2 unterschiedlichen PC's mit je 1 Mal Win8 und Win7. Alleine mit Win8 läuft alles prima. Alleine mit Win7 haben wir ebenfalls Probleme.

Eine alte gewachsene DB kann ich nicht von heute auf morgen mit ODBC auf den SQL Server verschieben. Da braucht es einiges an Aufwand, um das Frontend zu optimieren, damit die Performance nicht in den Keller geht. Dieser Lösungsweg scheidet für die kurzfristige Störungsbehebung defnitiv aus.

An dieser Stelle nochmals die dringende Frage, ob jemand von Euch Erfahrungen mit einem Netzwerk mit Windows Server 2012 R2 hat, in dem ein Access-Frontend auf mehreren PC's mit Win7 und Win8 (und evt. noch XP) läuft.

Wenn ja, ist schon jemals der Fehler "unbekanntes Datenbankformat" aufgetreten oder gibt es Konfigurationsrichtlinien, die man auf dem Server oder auf den PC's beachten muss, beispielsweise das "Opportunistic Locking".

Danke für Eure Hilfe
Franz

 

Hi Franz,

anscheinend kann man Opportunistic Locking nicht deaktiveren auf dem Server 2012, man kann offenbar lediglich SMB2/3 komplett abschalten. Wahrscheinlich müsste man SMB2/3 dann auch auf allen Clients deaktivieren.

Da davon jedoch überall abgeraten wird, habe ich das noch nie gemacht.

Gruß Sten

 

Hi Sten

Ich hatte gestern Abend die gleiche Diskussion mit dem Serverspezialisten. Wir sind der Meinung, dass SMB3 das Problem sein könnte und wir teilen auch Deine Einschätzung dass sich das Opportunistic Locking anscheinend nicht abschalten lässt und dass das Abschalten von SMB 2/3 weitere Probleme verursachen könnte und deshalb nicht empfehlenswert ist.

Damit steht noch immer die Frage im Raum, ob Access-Backends auf einem Server 2012 R2 mit Frontends auf Win7- und Win8-PC's und evt. WinXP zum Fehler "nicht erkennbares Datenbankformat" führen. SMB3 wurde für Win8 eingeführt und deshalb haben wir wahrscheinlich keine Probleme, wenn wir nur Frontends auf Win8-PC's in Betrieb haben. Sobald wir die Win8-PC's abschalten und nur Win7-PC's in Betrieb haben, kommt nach einiger Zeit die Fehlermeldung. Da ich jedoch niemand finde, der unsere Server-/PC-/Datenbank-Konfiguration hat, kann ich nicht 100% ausschliessen, dass nicht noch andere Ursachen verantwortlich sein können. Unser Win-XP PC's sind momentan abgeschaltet, damit wir diese bei der Fehleranalyse nicht auch noch berücksichtigen müssen.

Gruss
Franz

 

Hallo zusammen

Zusammenfassung der bisherigen Erkenntnisse:
- Windows Server 2012 R2
+ einige Windows 7 PC's + evt. einige Windows 8 PC's
+ Access Frontend und Access Backend
= sporadischer Datenbankfehler "Nicht erkennbares Datenbankformat"

Windows Server 2012 R2
+ Windows 8 PC's
+ Access Frontend und Access Backend
= Alles läuft prima

Wir haben heute Vormittag einen virtuellen Windows Server 2008 R2 aufgesetzt (Win 7 hätte zu wenig Freigaben) und die Access-Backenddatei auf diesen Server verschoben, im Frontend die Tabellen auf den neuen Server eingebunden und damit läuft mit der Datenbank alles prima.

Virenprogramm auf dem 2012 R2 kann ausgeschlossen werden, da das Access-Dateiverzeichnis ausgeklammert wurde.

Das Abschalten von SMB 3/2 ist definitiv keine Lösung.

Ich gehe davon aus, dass in den kommenden Monaten weitere Firmen auf Win Server 2012 R2 migrieren und ich schätze, dass dann viele Server-Administratoren, Access-Entwickler und Kunden lange Gesichter machen, wenn die Datenbanken nicht sauber laufen.

Quizfrage an Euch: Mit welchen weiteren Ideen kann man dieses Problem lösen?

Gruss
Franz

 

Hi,

weitere Ideen:

A)
Ist das noch ein JET-Backend im mdb-Format? Ggf. ändert sich was mit der ACE-Engine im accdb-Format...

B)
Ggf. könnte man einen File-Server mit Linux/Samba aufsetzen und ausprobieren. Ubuntu LTS hat die Hyper-V Treiber IIRC bereits dabei.

Bzgl. Win 2k8R2:

Wenn das bei Dir sauber laufen sollte (ohne die XP-Clients), dann könnte man auf die Idee kommen, dass der File-Server immer zum jeweils ältesten Windows-Client passen sollte... In diesem Fall dann SMB2?

 

Hallo Sten

Wir haben beim Kunden inzwischen auch die XP-PC's (keine Diskussion darüber bitte!) wieder in Betrieb und seit das Backend auf einem 2008 R2 liegt, läuft wieder alles prima.

A) Es ist noch ein mdb-Backend. Dein Hinweis ist gut, ich kann ihn jedoch nicht testen, da die User erst einmal in aller Ruhe wieder aufarbeiten müssen.

B) Auch eine Möglichkeit. Ich persönlich erwarte jedoch, dass ein MS-Server auch alle MS-Programme korrekt abwickeln kann.

C) Deine Idee mit dem SMB, passend zum tiefsten Client, scheint mir sehr plausibel zu sein.

Da wir bei uns noch einen Server 2008 R2 haben, kann ich A) und C) leider nicht simulieren und testen und bei Kunden mit Server 2012 R2 geht das auch nicht gut.

Vielleicht ist ein Mitleser unter uns, der eine ähnliche Konstellation hat und darüber genauere Aussagen machen kann.

Gruss
Franz