Benutzer mit den meisten Antworten
Keine ODBC Verbinung unter WIN 7 64Bit + Access 2007 -- SQL 2008

Frage
-
Hallo zusammen,
ich habe heute ein sehr interessantes Problem.
Ich konnte mit dem WIN 7 Pro 64Bit immer keine Verbindung zum SQL Server via ODBC herstellen.
Das System besteht aus
1 x SBS 2008 Premium darauf eine SQL 2008 64Bit
8x Win XP Pro 32Bit mit Access 2007
1 x Win 7 Pro 64Bit mit Access 2007
Ich habe wie gewohnt unter dem ODBC Administrator (Rechte Maus -als Administrator starten) eine System-DSN erfolgreich zum SQL Server mit dem Win 7 PC erstellt.
Meldung unter Access – keine ODBC Verbindung möglich.
Dann habe ich eine Benutzer-DSN erstellt.
Langes warten -- Server-Fehler 67 und 17 Zugriff verweigert oder Sever nicht erreichbar.
mmhh
Dann habe ich eine neue Access DB erstellt und wollt per – externe Daten – weitere – Erstelle Sie eine Verknüpfung zur Datenquelle … - Reiter „Computerdatenquelle“ die erstelle System-DSN auswählen. Die war da nicht zu finden. Es war nur die Benutzer-DSN vorhaben, aber mit der durfte ich nicht Zugreifen.
Darauf habe ich mir die ODBC.ini angesehen. Dort war kein Eintrag.
Ein Blick in die Regedit ergab folgendes:
Der Eintrag den ich unter dem „odbcad32.exe“ erstellt habe wurde in HKLM\Software\ODBC\ODBC.INI\ abgelegt.
Wenn ich unter Access direkt einen neuen ODBC SYSTEM-DSN Eintrag erstelle, erscheint er in der ODBC.ini und wird in der Registry unter HKLM\Software\Wow6432Node\ODBC\ODBC.INI\ abgelegt.
Leider kann ich diesen Eintrag dort in Access nicht bearbeitet – sprich weder löschen noch ändern.
Nachdem dieser Eintrag erstellt wurde und mit den aktuellen dynamischen Port 21625 (nicht selber finden lassen), hatte ich Zugriff auf die DB.
Nun wollte ich das wieder rausschmeißen und auf Dynamisch umstelle, nur wie?
Mit welchem Tool komme ich an den Eintrag, der Access erstellt wurde?
Wie erstelle ich sauber den System-DSN unter dem ODBC-Administrator, damit das auch unter Access benutzt werden kann?
Kennt einer das Problem?
Gruß
Mathias
Antworten
-
Danke Elmar,
Das hat mich wieder ein ganzes Stück nach vorne gebracht.
Ich konnte nun diverser weiterer Probleme auch fixen.
Das mit dem SQL Browser war schon eingerichtet.
Lösung war zum Schluss – ODBC für Benutzer-DSN und System-DSN unter 32Bit und 64Bit erstellen. In der richtigen Reihenfolge konnten dann zum Schluss auch die letzten dynamisch angelegt.
Danach trat ein Problem mit der „Vertrauenswürdigen Speicherort“ auf. Der alte musste komplett gelöscht werden, bevor die *.mdb bzw. *.mde auch akzeptiert wurde.
Das Problem aus dem anderen Fall, denke ich mal wird damit nichts zu tun haben. Dafür sprechen 5 Fakten für.
Es tritt nur bei einem User auf.
Er kann sofort an einem anderen PC weiter arbeiten
Es ist nicht PC gebunden
Und es kann nur durch einen Wiederherstellungspunkt behoben werden.
An defekten PC kann danach keiner mehr sich an dem Server anmelden.
Gruß
Mathias
- Als Antwort markiert Mathias Amenda Freitag, 16. Dezember 2011 17:17
- Tag als Antwort aufgehoben Mathias Amenda Freitag, 16. Dezember 2011 17:17
- Als Antwort markiert Mathias Amenda Freitag, 16. Dezember 2011 17:18
Alle Antworten
-
Hallo
Ich habe da noch einen Nachtrag.
Der Server wurde so nicht gleich erkannt. Ich musste in Access per Hand in eintragen.
Mit dem Hacken „Anschluss dynamisch bestimmen“ (stand 1433 grau hinterlegt) erschien diese Meldung:
Fehler bei der Verbindung:
SQLState: ´01000`
SQL Server-Fehler: 11001
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets] ConnectionOpen
(Connect()).
Fehler bei der Verbindung:
SQL State: `08001`
SQL Server-Fehler: 6
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]Der angegebene
SQL Server konnte nicht gefunden werden.
Mit genauer Angabe des aktuellen Port, war es kein Problem die Verbindung auf zu bauen.
Gruß
Mathias
-
Hallo Mathias,
um die ODBC Verwaltung für 32-Bit aufzurufen musst Du odbccad32.exe
aus dem Verzeichnis %WINDIR%\SysWOW64aufrufenBei ODBC ist es ein Unterschied, ob Du mit einer 32-Bit oder 64-Bit Anwendung zugreifst,
denn die Treiber müssen jeweils zueinander passen.
Und Access 2007 ist eine 32 Bit Anwendung (erst mit Office 2010 gibt es eine 64-Bit Version).ODBC verwendet dafür zwei verschiedene Registry Zweige und Einträge gelten
jeweils nur für 32 oder 64 Bit Anwendungen.
Der Wow6432Node gilt allgemein für alle 32-Bit Anwendungen.Was das "Finden" angeht (und wohl mit Deinem anderen Beitrag zusammenhängt):
Wenn der SQL Server dynamische Ports verwendet, so muss der SQL Server Browser Dienst laufen.
Und der dafür benötigte Port (1434/UDP) sowohl auf Server wie auf dem Client durch die Firewall freigeschaltet sein.Probleme mit dynamischen Ports kann man vermeiden, in dem man in der SQL Server Netzwerkkonfiguration
einen festen Port hinterlegt. Für beide (dynamische wie feste) gilt ebenso, dass die Firewall sie durchlassen muss:
Vorgehensweise: Konfigurieren einer Windows-Firewall für DatenbankmodulzugriffGruß Elmar
-
Danke Elmar,
Das hat mich wieder ein ganzes Stück nach vorne gebracht.
Ich konnte nun diverser weiterer Probleme auch fixen.
Das mit dem SQL Browser war schon eingerichtet.
Lösung war zum Schluss – ODBC für Benutzer-DSN und System-DSN unter 32Bit und 64Bit erstellen. In der richtigen Reihenfolge konnten dann zum Schluss auch die letzten dynamisch angelegt.
Danach trat ein Problem mit der „Vertrauenswürdigen Speicherort“ auf. Der alte musste komplett gelöscht werden, bevor die *.mdb bzw. *.mde auch akzeptiert wurde.
Das Problem aus dem anderen Fall, denke ich mal wird damit nichts zu tun haben. Dafür sprechen 5 Fakten für.
Es tritt nur bei einem User auf.
Er kann sofort an einem anderen PC weiter arbeiten
Es ist nicht PC gebunden
Und es kann nur durch einen Wiederherstellungspunkt behoben werden.
An defekten PC kann danach keiner mehr sich an dem Server anmelden.
Gruß
Mathias
- Als Antwort markiert Mathias Amenda Freitag, 16. Dezember 2011 17:17
- Tag als Antwort aufgehoben Mathias Amenda Freitag, 16. Dezember 2011 17:17
- Als Antwort markiert Mathias Amenda Freitag, 16. Dezember 2011 17:18