Ich arbeite mit einem kleinen Unternehmen zusammen, das eine Access-basierte Datenbank für die Auftragsverwaltung verwendet. Das System gibt es schon seit Jahren und sie haben 6-7 PCs, die benutzerdefinierte Software von einem ISV verwenden, um auf die Datenbank zuzugreifen. Der Zugriff auf die Datenbank erfolgt über eine Verbindung über ein zugeordnetes Laufwerk (Z:).
Vor einigen Monaten trat dieser Fehler sporadisch auf:
Datenquellenname nicht gefunden und kein Standardtreiber angegeben
Dies führt dazu, dass der ISV eine Verbindung zur Datenbank herstellen und eine Reparatur durchführen muss, um die Datenbank wiederherzustellen. Der angezeigte Fehler ist etwas spezifischer und deutet darauf hin, dass das Dateiformat beschädigt ist. Der Support-Techniker vermutet, dass das Problem durch eine fehlgeschlagene Transaktion im Netzwerk verursacht wird. Zu diesem Zweck haben wir verschiedene Dinge ausprobiert
- die Datenbank auf einen anderen Host verschoben, falls es auf dem ursprünglichen „Server“-PC Probleme geben sollte
- den Netzwerk-Switch ersetzt
- begann, die Clients nacheinander vom Netzwerk zu nehmen, um das Problemkind zu isolieren, ohne einheitliche Ergebnisse
Bisher ohne Erfolg.
Meine Frage(n): Könnte einer der PCs seine Laufwerkszuordnung schließen und die geöffnete Datenbank beschädigen? Gibt es irgendetwas Neues in Windows 7, das dem im Weg stehen könnte? Können Sie einen besseren Ansatz zum Isolieren der Ursache empfehlen?
Antwort1
Dies ist mit ziemlicher Sicherheit ein 32-Bit-DSN-Problem im Vergleich zu 64-Bit-DSN. Um einen 32-Bit-DSN in einer 64-Bit-Umgebung zu verwenden, gehen Sie zuC:\Windows\SysWoW64\odbcad32.exe
Unsere interne Anwendung hat eine sehr ähnliche Einschränkung. Um das Problem in Zukunft zu vermeiden, sollten Sie die neueste Version installieren.SQL Server Native Clientund stellen Sie sowohl den 32-Bit- als auch den 64-Bit-DSN über die Gruppenrichtlinie auf jedem Computer bereit.
Antwort2
Wenn Sie das Laufwerk mit dem Befehl SUBST.exe statt mit „NET USE“ zuordnen, wird die Verbindung im Gegensatz zu „NET USE“ immer erneut versucht, wenn das zugeordnete Laufwerk verloren geht. Bedenken Sie, dass es auf diese Weise für Personen, die den Befehl SUBST.exe nicht kennen, schwierig ist, das Laufwerk zu entkoppeln. Wenn ein Laufwerk auf diese Weise zugeordnet ist, können Sie es nicht einfach vom Windows-Explorer trennen ... das funktioniert nicht.
Ich persönlich stimme zu, dass es das 64-Bit-Problem ist.
Beachten Sie, dass die 32-Bit- und 64-Bit-ODBC-DSN-Kontrollfelder zwar auf eine bestimmte Weise funktionieren, in manchen Fällen jedoch das Gegenteil tun. Beispiel: Wenn Sie auf einem 64-Bit-System versuchen, einen 64-Bit-„Benutzer-DSN“ hinzuzufügen, stellen Sie möglicherweise fest, dass Ihre Verbindung fehlschlägt, aber mit einem „System-DSN“ funktioniert es. Dies liegt daran, dass das ODBC-Feld tatsächlich einen „32-Bit-DSN“ auf der Registerkarte „Benutzer“ des 64-Bit-ODBC-Kontrollfelds generiert, während es den erwarteten 64-Bit-DSN auf der Registerkarte „System“ generiert. Solange Sie sich der Möglichkeit bewusst sind, dass die Kontrollfelder nicht wie erwartet funktionieren, wird Sie meiner Meinung nach keine Konfiguration vor Probleme stellen.