Zugriff auf SQL-Server nicht möglich: Unterschied zwischen den Versionen

Aus GEVITAS
Wechseln zu: Navigation, Suche
(Überbleibsel von alten Installationen)
(Überbleibsel von alten Installationen)
 
(21 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 16: Zeile 16:
  
 
* Definieren Sie in der [http://de.wikipedia.org/wiki/Firewall Firewall], dass bestimmte [http://de.wikipedia.org/wiki/Port_(Protokoll) Port]s für den eingehenden und ausgehenden Zugriff freigeschaltet sind:
 
* Definieren Sie in der [http://de.wikipedia.org/wiki/Firewall Firewall], dass bestimmte [http://de.wikipedia.org/wiki/Port_(Protokoll) Port]s für den eingehenden und ausgehenden Zugriff freigeschaltet sind:
 +
;Alternativ dazu können Sie aus die SQL-Server-Exe frei geben, z.B.:
 +
:"C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Binn\sqlservr.exe" (SQL-Server 2014)
 +
 +
 +
==== Microsoft SQL-Server© ====
  
;Microsoft SQL-Server©:
 
 
* MS-SQL-Server benutzt standardmäßig den TCP/IP-Port '''1433'''.
 
* MS-SQL-Server benutzt standardmäßig den TCP/IP-Port '''1433'''.
 
* Der MS-SQL-Dienst '''SQL Server Browser''' ist für die Kommunikation des SQL-Server-Dienstes mit dem Netzwerk zuständig. Er benutzt das Protokoll '''UDP''' mit dem Port '''1434'''.
 
* Der MS-SQL-Dienst '''SQL Server Browser''' ist für die Kommunikation des SQL-Server-Dienstes mit dem Netzwerk zuständig. Er benutzt das Protokoll '''UDP''' mit dem Port '''1434'''.
;MySQL©:
+
* Falls Sie über TCP/IP keinen Zugriff zum Microsoft-SQL-Server erhalten, können Sie im ODBC-Treiber auch den Zugriff über “Named-Pipes” aktivieren. Dieses Netzwerkprotokoll wird vom SQL-Server standardmäßig ebenfalls unterstützt. Es ist allerdings nicht routingfähig und auch nicht mehr besonders modern, so dass es eigentlich nicht mehr verwendet werden soll.
 +
 
 +
;Alternative zum Freigeben von Ports:
 +
:Aus Sicherheitsgründen ist es empfehlenswert, die '''Programmdatei''' des SQL-Servers in der Firewall als Ausnahme für eingehende und ausgehende Verbindungen festzulegen.
 +
:Dazu trägt man die Programmdatei im Ordner
 +
 
 +
C:\Program Files\Microsoft SQL Server\MSSQL12.<instance_name>\MSSQL\Binn
 +
 
 +
:(Hinweis: Die Programmdatei befindet sich in dem Ordner, der bei der Installation als Stamm-Ordner der Instanz angegeben wurde! Wenn Sie hier z.B. "D:\MSSQL\Data" angegeben haben, dann befindet sich die Programmdatei für SQL.Server 2012 in '''D:\MSSQL\Data\MSSQL12.MSSQLSERVER\MSSQL\Binn''')
 +
 +
:und die Datei
 +
 
 +
sqlservr.exe
 +
 
 +
:in die Firewall als Ausnahme ein.
 +
 
 +
Siehe auch:
 +
 
 +
* [http://windows.microsoft.com/de-de/windows/communicate-through-windows-firewall#1TC=windows-7 Zulassen der Kommunikation eines Programms über die Windows-Firewall]
 +
 
 +
* [https://msdn.microsoft.com/de-de/library/cc646023.aspx Konfigurieren der Windows-Firewall für den SQL Server-Zugriff].
 +
 
 +
==== MySQL&copy; ====
 +
 
 
* mySQL benutzt standardmäßig den TCP/IP-Port '''3306'''.
 
* mySQL benutzt standardmäßig den TCP/IP-Port '''3306'''.
;ORACLE&copy;:
+
 
 +
==== ORACLE&copy; ====
 +
 
 
* ORACLE benutzt standardmäßig den TCP/IP-Port '''1521'''.
 
* ORACLE benutzt standardmäßig den TCP/IP-Port '''1521'''.
 
* Diese müss ggf. in der Firewall freigeschaltet werden.
 
* Diese müss ggf. in der Firewall freigeschaltet werden.
  
* Falls Sie über TCP/IP keinen Zugriff zum Microsoft-SQL-Server erhalten, können Sie im ODBC-Treiber auch den Zugriff über “Named-Pipes” aktivieren. Dieses Netzwerkprotokoll wird vom SQL-Server standardmäßig ebenfalls unterstützt. Es ist allerdings nicht routingfähig und auch nicht mehr besonders modern, so dass es eigentlich nicht mehr verwendet werden soll.
+
=== Tipps ===
  
 
* Auch einige '''Virenscanner'''(z.B. TrendMicro) verhindern das ordnungsgemäße installieren. In diesem Fall muss der Virenscanner zeitweise deaktiviert werden.
 
* Auch einige '''Virenscanner'''(z.B. TrendMicro) verhindern das ordnungsgemäße installieren. In diesem Fall muss der Virenscanner zeitweise deaktiviert werden.
  
 
* Wie Sie die Windows-Firewall einstellen müssen, wird [http://msdn.microsoft.com/de-de/library/ms175043.aspx hier] beschrieben.
 
* Wie Sie die Windows-Firewall einstellen müssen, wird [http://msdn.microsoft.com/de-de/library/ms175043.aspx hier] beschrieben.
 +
 +
* Alternativ zum '''Freischalten bestimmter Ports''' können Sie auch '''bestimmten Programmen''' den Zugriff freischalten, wie unter [http://windows.microsoft.com/de-de/windows/communicate-through-windows-firewall#1TC=windows-7 Zulassen der Kommunikation eines Programms über die Windows-Firewall] beschrieben. Auch interessant ist der Artikel [https://msdn.microsoft.com/de-de/library/cc646023.aspx Konfigurieren der Windows-Firewall für den SQL Server-Zugriff].
  
 
* Ob die Firewall den Zugriff behindert können Sie ganz einfach testen:
 
* Ob die Firewall den Zugriff behindert können Sie ganz einfach testen:
Zeile 44: Zeile 75:
 
=== Einstellungen auf dem Rechner ===
 
=== Einstellungen auf dem Rechner ===
  
* Prüfen Sie alle Einstellungen sehr genau:
+
==== Einstellungen prüfen ====
** [http://de.wikipedia.org/wiki/ODBC ODBC]: Können Sie eine Verbindung über die [http://de.wikipedia.org/wiki/ODBC ODBC] herstellen, aber nicht über das Programm? Dann stimmt Ihre Einstellung in der [[INI-Datei]] nicht!
+
 
** [http://de.wikipedia.org/wiki/Oracle_(Datenbanksystem) Oracle]: Können Sie die Verbindung über den .Net-Konfigurations-Assistenten testen? Wenn dieser funktioniert, stimmt Ihre Einstellung in der [[INI-Datei]] nicht!
+
Prüfen Sie alle Einstellungen sehr genau:
** [http://de.wikipedia.org/wiki/Oracle_(Datenbanksystem) Oracle]: Prüfen Sie die Einstellungen des Netzwerk-Protokolls! Ist überall das gleiche Protokoll ([http://de.wikipedia.org/wiki/TCP/IP TCP/IP] oder TNS) angegeben?
+
* [http://de.wikipedia.org/wiki/ODBC ODBC]: Können Sie eine Verbindung über die [http://de.wikipedia.org/wiki/ODBC ODBC] herstellen, aber nicht über das Programm? Dann stimmt Ihre Einstellung in der [[INI-Datei]] nicht!
* Unter '''Windows 8&copy;''' oder '''Windows Server 2012&copy;''' kann es zu Problemen kommen, wenn man '''dynamische Anschlüsse''' verwendet. In diesem Fall empfiehlt es sich, in der ODBC-Datenquelle den Anschluss (=Port) fest zu vergeben. Das trägt im ODBC-Datenquellen-Manager unter <code>Clientkonfiguration</code> so ein:<br>
+
* [http://de.wikipedia.org/wiki/Oracle_(Datenbanksystem) Oracle]: Können Sie die Verbindung über den .Net-Konfigurations-Assistenten testen? Wenn dieser funktioniert, stimmt Ihre Einstellung in der [[INI-Datei]] nicht!
 +
* [http://de.wikipedia.org/wiki/Oracle_(Datenbanksystem) Oracle]: Prüfen Sie die Einstellungen des Netzwerk-Protokolls! Ist überall das gleiche Protokoll ([http://de.wikipedia.org/wiki/TCP/IP TCP/IP] oder TNS) angegeben?
 +
 
 +
==== Dynamische Ports ====
 +
 
 +
Unter '''Windows 8&copy;''' oder '''Windows Server 2012&copy;''' kann es zu Problemen kommen, wenn man '''dynamische Anschlüsse''' verwendet. In diesem Fall empfiehlt es sich, in der ODBC-Datenquelle den Anschluss (=Port) fest zu vergeben. Das trägt im ODBC-Datenquellen-Manager unter <code>Clientkonfiguration</code> so ein:<br>
 +
 
 
[[Datei:REFLEX_Installation_SQLServer_Windows8_ODBC_Anschluss_dynamisch.jpg]]<br>
 
[[Datei:REFLEX_Installation_SQLServer_Windows8_ODBC_Anschluss_dynamisch.jpg]]<br>
* In der Firewall kann man dann gezielt diesen Port freigeben!
+
 
 +
In der Firewall kann man dann gezielt diesen Port freigeben!
 +
 
 +
Wie '''[https://msdn.microsoft.com/de-de/library/cc646023.aspx hier]''' beschrieben, benutzen '''benannte Instanzen''' von MS-SQL-Server dynamische Ports. In diesem Fall bleibt Ihnen gar nichts anderes übrig, als die SQL-Server-'''Programme''' in der Firewall freizuschalten. Warum? Nun, "dynamische Ports" heißt, dass der Treiber einen freien Port sucht und diesen verwendet. Man weiß nicht, welcher Port das ist! Wie sollte man also einen Port in der Firewall freigeben?
 +
 
 +
* '''Microsoft&copy; sagt in dem '''[https://msdn.microsoft.com/de-de/library/cc646023.aspx Artikel]''', dass durch Updates oder Patches die Firewall-Regel außer Kraft gesetzt werden kann. Das bedeutet, dass u.U. nach einem Update des SQL-Servers die Firewall-Regel neu gesetzt werden muss!''' [[Datei:Achtung_64.jpg|rechts]]
  
 
=== Protokolle auf dem Server ===
 
=== Protokolle auf dem Server ===
Zeile 57: Zeile 99:
  
 
Öffnen Sie den SQL-Server-Konfigurations-Manager...
 
Öffnen Sie den SQL-Server-Konfigurations-Manager...
 +
 
* Windows XP/7: Start&rArr;Programme&rArr;Microsoft SQL-Server&rArr;Konfigurationstools&rArr;SQL-Server-Konfigurations-Manager
 
* Windows XP/7: Start&rArr;Programme&rArr;Microsoft SQL-Server&rArr;Konfigurationstools&rArr;SQL-Server-Konfigurations-Manager
* Windows 8: Die Kachel für den SQL-Server-Konfigurations-Manager befindet sich anfangs ziemlich weit rechts
+
 
 +
* Windows 8/Server 2012: Die Kachel für den SQL-Server-Konfigurations-Manager befindet sich anfangs ziemlich weit rechts
 +
 
 
[[Datei:REFLEX_Installation_SQLServer_KonfigManager_Win8.jpg|thumb]]
 
[[Datei:REFLEX_Installation_SQLServer_KonfigManager_Win8.jpg|thumb]]
  
Zeile 65: Zeile 110:
 
[[Datei:REFLEX_Installation_SQLServer_Protokolle.jpg]]
 
[[Datei:REFLEX_Installation_SQLServer_Protokolle.jpg]]
  
Wenn unter <code>Dynamische TCP-Ports</code> eine "0" steht, entfernen Sie diese!
+
Wenn unter <code>Dynamische TCP-Ports</code> eine "0" steht, entfernen Sie diese! Beachten Sie hierbei aber [https://msdn.microsoft.com/de-de/library/cc646023.aspx Konfigurieren der Windows-Firewall für den SQL Server-Zugriff].
  
 
Tragen Sie unter <code>TCP-Port</code> den Standard-Port für SQL-Server "1433" ein.
 
Tragen Sie unter <code>TCP-Port</code> den Standard-Port für SQL-Server "1433" ein.
Zeile 88: Zeile 133:
 
=== Überbleibsel von alten Installationen ===
 
=== Überbleibsel von alten Installationen ===
  
Besonders perfide können Fragmente von früheren SQL-Server-Installationen sein! Im konkreten Fall stellte sich die Situation wie folgt dar:
+
Besonders perfide können Fragmente von früheren SQL-Server-Installationen sein! Im konkreten Fall stellte sich heraus, dass der SQL-Browser-Dienst einer früheren SQL-Installation trotz de-installieren noch lief und den Port 1433 abhörte. Das verhinderte, dass der neu-installierte SQL-Server-Dienst die Anfrage auf Port 1433 bekam und so die Anfrag immer ins Leere lief!
 
 
* Es wurde ein virtueller Server aus einem anderen, '''lauffähigen''' Server "geklont", also das Image des Servers für den neuen Server kopiert. Auf diesem Server war SQL-Server 2008&copy; (=Version 10.0) installiert. Dieser wurde '''de-installiert''', der Rechner mehrmals neu gestartet.
 
* Dann wurde '''SQL-Server 2014 Express Edition&copy;''' (=Version 12.0) installiert, und zwar nicht in der Standard-Instanz sondern in einer '''benannten Instanz'''.
 
* Es wurde versucht, eine neue Datenbank durch '''Wiederherstellen eines Backups anzulegen'''. Dies scheiterte, weil die Backup-Datei nicht als solche erkannt wurde. Zudem gab es mehrere unerklärliche Fehlermeldung auf den Server. Da man annahm, dass die Backup-Datei (aus SQL-Server 2012) nicht kompatibel zu SQL-Server 2014 war, wurde SQL-Server 2014 wieder '''de-installiert'''.
 
** Diese Annahme stellte sich als falsch heraus, s.u.
 
* Dann wurde '''SQL-Server 2012 Express Edition&copy;''' (=Version 11.0) installiert, und zwar nicht in der Standard-Instanz sondern auch in einer benannten Instanz.
 
* Es wurde wieder versucht, eine neue Datenbank durch wiederherstellen des Backups anzulegen. Dies scheiterte aber auch, weil:
 
** die Backup-Datei nicht ausgewählt werden konnte, der Pfad zu der Datei wurde im Wiederherstellungs-Dialog nicht angezeigt.
 
** die Backup-Datei nicht als solche erkannt wurde, genau wie zuvor! Nach Kopieren der Datei nach "C:\" konnte die Datei ausgewählt werden und die Wiederherstellung funktionierte!
 
* Die oben angenommene Inkompatibilität war also keine, sondern ein Server-Problem: Dem angemeldeten User musste das volle Zugriffsrecht auf das Verzeichnis gegeben werden, in dem die Backup-Datei lag.
 
 
 
'''So weit die Vorgeschichte, nun zum eigentlichen Problem''':
 
 
 
* Nachdem nun ein funktionsfähiger SQL-Server mit Datenbank zur Verfügung stand, wurde die Software auf einem Client-Rechner installiert und der ODBC-Eintrag dazu gemacht.
 
 
 
* Beim Versuch zu dem SQL-Server Kontakt aufzunehmen, wurde nach einigen Sekunden angezeigt "Server existiert nicht oder Zugriff verweigert"!
 
 
 
* Nun folgten die üblichen Maßnahmen, also
 
 
 
** [[Zugriff_auf_SQL-Server_nicht_möglich#Firewall|Firewall-Port-Freigabe]]
 
** [[Zugriff_auf_SQL-Server_nicht_möglich#Protokolle_auf_dem_Server|TCP/IP-Protokoll auf Server aktivieren und einstellen]
 
** Port 1433 in der ODBC-Konfiguration festlegen (statt "Anschluss dynamisch bestimmen"-Option.
 
 
 
* Nach stundenlangen Versuche mit wachsender Begeisterung wurde die Firewall '''ausgeschaltet'''.
 
 
 
* Dabei stellte man fest, dass der Kontakt zum SQL-Server und zur Datenbank erfolgreich war, wenn
 
** die Firewall ausgeschaltet war '''und'''
 
** die Option "Anschluss dynamisch bestimmen" im ODBC-Treiber eingestellt war!
 
* Mit festem Port 1433 in der ODBC-Konfiguration wurde der SQL-Server '''nicht gefunden!'''
 
 
 
Ein TCP-Protocol-Analyzer bewies, dass auf Port 1433 eine Anfrage vom Client gesendet wurde und vom Server mit "Reset" (also abweisen) beantwortet wurde! Warum machte der SQL-Server das?
 
 
 
Nun, die Antwort ist (im Nachinhein) einfach: '''Der SQL-Server antwortete gar nicht, sondern ein Überbleibsel einer früheren SQL-Server 2005 (!) Installation'''!
 
  
Im Task-Manager gab es einen Task (SQL-Server Browser). Beim Klicken mit der rechten Maustaste und "Dateipfad öffnen" öffnete sich
+
* Prüfen Sie deshalb im Task-Manager, ob es Prozesse (Dienste, Programme) gibt, die mit SQL-Server zu tun haben, aber dort nicht sein sollten.
  
C:\Program Files\Microsoft SQL Server\90
+
* Prüfen Sie, ob es im Verzeichnis "C:\Programme\Microsoft SQL Server" Verzeichnisse gibt, die von alten SQL-Server-Installationen stammen:
  
Das bedeutete, dass eine frühere Installation nicht vollständig de-installiert wurde! '''Dieses Programm''' und nicht der neu-installierte SQL-Server reagierte auf die Anfrage auf Port 1433 und versuchte, die Anfrage zu seiner SQL-Server-Instanz weiterzureichen. Die gab es aber gar nicht mehr, die Anfrage wurde also abgelehnt!
+
{| class="wikitable" style="text-align: left;"
 +
!Verzeichnis
 +
!Version
 +
|- valign="top"
 +
|80
 +
|SQL-Server&copy; 2003
 +
|- valign="top"
 +
|90
 +
|SQL-Server&copy; 2005
 +
|- valign="top"
 +
|100
 +
|SQL-Server&copy; 2008
 +
|- valign="top"
 +
|110
 +
|SQL-Server&copy; 2012
 +
|- valign="top"
 +
|120
 +
|SQL-Server&copy; 2014
 +
|- valign="top"
 +
|130
 +
|SQL-Server&copy; 2016
 +
|- valign="top"
 +
|140
 +
|SQL-Server&copy; 2017
 +
|- valign="top"
 +
|150
 +
|SQL-Server&copy; 2019
 +
|}
  
Das war auch die Erklärung dafür, dass der SQL-Server auf dynamischen Ports angesprochen werden konnte, nur auf dem Port 1433 nicht.
+
Zum Testen können Sie ein verdächtiges Verzeichnis umbenennen, den Server neu starten und prüfen, ob das Problem dadurch beseitigt wurde. Wenn ja, benutzen Sie ein Tool, um die Registry aufzuräumen, also z.B. Verweise auf automatisch zu startende Prozesse zu entfernen, die nicht mehr existieren.
  
 +
Einzelheiten dazu finden Sie hier:
  
 
+
[[Zugriff auf SQL-Server nicht möglich wegen Überbleibsel]]
 
 
 
 
(Ob die oben angegebene Reihenfolge und die verschiedenen Versionsnummer entscheidend sind, ist nicht bekannt)
 
  
 
== Links ==
 
== Links ==
Zeile 157: Zeile 194:
 
* [[REFLEX-Installation: Client-Installation: Programm installieren|Client-Installation: Programm installieren]]
 
* [[REFLEX-Installation: Client-Installation: Programm installieren|Client-Installation: Programm installieren]]
  
* ''Bekannte Probleme bei der Installation''
+
* [http://windows.microsoft.com/de-de/windows/communicate-through-windows-firewall#1TC=windows-7 Zulassen der Kommunikation eines Programms über die Windows-Firewall]
 +
 
 +
* [https://msdn.microsoft.com/de-de/library/cc646023.aspx Konfigurieren der Windows-Firewall für den SQL Server-Zugriff]

Aktuelle Version vom 23. April 2021, 11:39 Uhr

1 Allgemeines

Der Zugriff vom Client auf den SQL-Server erfolgt immer über ein Netzwerk-Protokoll. Auch wenn Sie den SQL-Server auf dem gleichen Rechner haben, wird die Kommunikation über ein Netzwerk-Protokoll gehen, im Regelfall TCP/IP.

2 Fehler-Möglichkeiten

Es gibt natürlich viele Möglichkeiten, warum der Zugriff auf den SQL-Server nicht funktioniert. Hier können nur die gängigsten, bekannten Probleme und Lösungen aufgeführt werden.

2.1 Firewall

Wenn man davon ausgeht, dass alle Einstellungen korrekt sind und trotzdem kein Kontakt zum SQL-Server hergestellt werden kann, ist die Firewall der erste "Verdächtige".

  • Prüfen Sie, ob eine Firewall auf dem Server und dem Arbeitsplatz-Rechner aktiv ist.
  • Schalten Sie - wenn möglich - die Firewall auf dem Client und dem Server zum Test aus und versuchen Sie, ob dann die Verbindung möglich ist. Das ist natürlich nur eine Maßnahme für eine kurze Zeit.
  • Definieren Sie in der Firewall, dass bestimmte Ports für den eingehenden und ausgehenden Zugriff freigeschaltet sind:
Alternativ dazu können Sie aus die SQL-Server-Exe frei geben, z.B.
"C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Binn\sqlservr.exe" (SQL-Server 2014)


2.1.1 Microsoft SQL-Server©

  • MS-SQL-Server benutzt standardmäßig den TCP/IP-Port 1433.
  • Der MS-SQL-Dienst SQL Server Browser ist für die Kommunikation des SQL-Server-Dienstes mit dem Netzwerk zuständig. Er benutzt das Protokoll UDP mit dem Port 1434.
  • Falls Sie über TCP/IP keinen Zugriff zum Microsoft-SQL-Server erhalten, können Sie im ODBC-Treiber auch den Zugriff über “Named-Pipes” aktivieren. Dieses Netzwerkprotokoll wird vom SQL-Server standardmäßig ebenfalls unterstützt. Es ist allerdings nicht routingfähig und auch nicht mehr besonders modern, so dass es eigentlich nicht mehr verwendet werden soll.
Alternative zum Freigeben von Ports
Aus Sicherheitsgründen ist es empfehlenswert, die Programmdatei des SQL-Servers in der Firewall als Ausnahme für eingehende und ausgehende Verbindungen festzulegen.
Dazu trägt man die Programmdatei im Ordner
C:\Program Files\Microsoft SQL Server\MSSQL12.<instance_name>\MSSQL\Binn
(Hinweis: Die Programmdatei befindet sich in dem Ordner, der bei der Installation als Stamm-Ordner der Instanz angegeben wurde! Wenn Sie hier z.B. "D:\MSSQL\Data" angegeben haben, dann befindet sich die Programmdatei für SQL.Server 2012 in D:\MSSQL\Data\MSSQL12.MSSQLSERVER\MSSQL\Binn)
und die Datei
sqlservr.exe
in die Firewall als Ausnahme ein.

Siehe auch:

2.1.2 MySQL©

  • mySQL benutzt standardmäßig den TCP/IP-Port 3306.

2.1.3 ORACLE©

  • ORACLE benutzt standardmäßig den TCP/IP-Port 1521.
  • Diese müss ggf. in der Firewall freigeschaltet werden.

2.2 Tipps

  • Auch einige Virenscanner(z.B. TrendMicro) verhindern das ordnungsgemäße installieren. In diesem Fall muss der Virenscanner zeitweise deaktiviert werden.
  • Wie Sie die Windows-Firewall einstellen müssen, wird hier beschrieben.
  • Ob die Firewall den Zugriff behindert können Sie ganz einfach testen:
    • Schalten Sie die Firewall (kurzfristig!) aus und testen Sie den Zugriff auf den SQL-Server z.B. über den ODBC-Manager. Funktioniert der Zugriff nun, ist die Firewall der Übeltäter!
  • Prüfen Sie, ob der Zugang zum SQL-Server auf dem Server selbst möglich ist:
    • Gehen Sie dazu z.B. in die ODBC-Datenquellen (Systemsteuerung --> Verwaltung oder "C:\Windows\SysWow64\odbcad32.exe").
    • Öffnen Sie den Reiter "System DSN" und klicken auf Hinzufügen. Wählen Sie den Treiber "SQL Server" --> Fertig stellen.
    • Geben Sie einen beliebigen Namen ein, die Beschreibung können Sie leer lassen. Nun geben Sie den Server-Namen und ggf.die Instanz an, z.B. "MYSERVER" oder "MYSERVER\Reflex" (Backslash, nicht Slash!). Klicken Sie auf Weiter.
    • Wenn die Windows-Authentifizierung auf dem SQL-Server aktiviert ist, belassen Sie es bei dieser Option. Ansonsten wählen Sie SQL Server Authentifizierung und geben den Benutzernamen und das Kennwort ein. Unter mySQL© ist nur die Server Authentifizierung möglich.
    • Klicken Sie dann auf Weiter. Der ODBC-Admin prüft nun, ob die Verbindung möglich ist. Wenn nicht, wird eine entsprechende Fehlermeldung angezeigt.

2.3 Einstellungen auf dem Rechner

2.3.1 Einstellungen prüfen

Prüfen Sie alle Einstellungen sehr genau:

  • ODBC: Können Sie eine Verbindung über die ODBC herstellen, aber nicht über das Programm? Dann stimmt Ihre Einstellung in der INI-Datei nicht!
  • Oracle: Können Sie die Verbindung über den .Net-Konfigurations-Assistenten testen? Wenn dieser funktioniert, stimmt Ihre Einstellung in der INI-Datei nicht!
  • Oracle: Prüfen Sie die Einstellungen des Netzwerk-Protokolls! Ist überall das gleiche Protokoll (TCP/IP oder TNS) angegeben?

2.3.2 Dynamische Ports

Unter Windows 8© oder Windows Server 2012© kann es zu Problemen kommen, wenn man dynamische Anschlüsse verwendet. In diesem Fall empfiehlt es sich, in der ODBC-Datenquelle den Anschluss (=Port) fest zu vergeben. Das trägt im ODBC-Datenquellen-Manager unter Clientkonfiguration so ein:

REFLEX Installation SQLServer Windows8 ODBC Anschluss dynamisch.jpg

In der Firewall kann man dann gezielt diesen Port freigeben!

Wie hier beschrieben, benutzen benannte Instanzen von MS-SQL-Server dynamische Ports. In diesem Fall bleibt Ihnen gar nichts anderes übrig, als die SQL-Server-Programme in der Firewall freizuschalten. Warum? Nun, "dynamische Ports" heißt, dass der Treiber einen freien Port sucht und diesen verwendet. Man weiß nicht, welcher Port das ist! Wie sollte man also einen Port in der Firewall freigeben?

  • Microsoft© sagt in dem Artikel, dass durch Updates oder Patches die Firewall-Regel außer Kraft gesetzt werden kann. Das bedeutet, dass u.U. nach einem Update des SQL-Servers die Firewall-Regel neu gesetzt werden muss!
    Achtung 64.jpg

2.4 Protokolle auf dem Server

Die Netzwerk-Protokolle auf dem Server könnten auch eine Fehlerquelle sein:

Öffnen Sie den SQL-Server-Konfigurations-Manager...

  • Windows XP/7: Start⇒Programme⇒Microsoft SQL-Server⇒Konfigurationstools⇒SQL-Server-Konfigurations-Manager
  • Windows 8/Server 2012: Die Kachel für den SQL-Server-Konfigurations-Manager befindet sich anfangs ziemlich weit rechts
REFLEX Installation SQLServer KonfigManager Win8.jpg

Klicken Sie auf SQl-Server NetzwerkkonfigurationProtokolle für SQL-Server.

REFLEX Installation SQLServer Protokolle.jpg

Wenn unter Dynamische TCP-Ports eine "0" steht, entfernen Sie diese! Beachten Sie hierbei aber Konfigurieren der Windows-Firewall für den SQL Server-Zugriff.

Tragen Sie unter TCP-Port den Standard-Port für SQL-Server "1433" ein.

Wiederholen Sie das für alle angezeigten IP-Nummern des Servers!

Die Änderungen wirken sich erst aus, wenn Sie den SQL-Server-Dienst neu starten! Das können Sie unter SQL-Server-Dienste mit der rechten Maustaste erledigen.

2.5 Zugriffsrechte

  • Hat der Benutzer Zugriffsrechte auf den SQL-Server und die Datenbank?
    • Wenn Sie über die Windows-Anmeldung (Domäne) zugreifen: Ist der Benutzer in der richtigen Gruppe zugewiesen?
    • Hat die Gruppe das Zugriffsrecht auf den SQL-Server?
    • Hat die Gruppe das Zugriffsrecht auf die Datenbank?

2.6 Server prinzipiell erreichbar?

  • Prüfen Sie von einem anderen Rechner, ob der Server prinzipiell über seinen Namen erreichbar ist. Dazu geben Sie am Server am Einfachsten ein Verzeichnis für alle frei und prüfen an dem anderen Rechner, ob Sie auf diese Freigabe zugreifen können.
    • Wenn JA, haben Sie definitiv ein SQL-Server-Problem! Normalerweise sind das immer die Einstellungen der Firewall, siehe diesen Artikel.
    • Wenn NEIN, haben Sie ein Netzwerkproblem! Da stellt sich die Frage, ob der Server mit seinem Namen angesprochen werden kann. Versuchen Sie testweise, den Server mit seiner IP-Adresse anzusprechen. Geben Sie dazu z.B. im ODBC-Manager anstelle es Namens die IP-Adresse an. Kann dann die Verbindung hergestellt werden, hat der Server ein Problem mit der Namensauflösung, also mit der DNS.

2.7 Überbleibsel von alten Installationen

Besonders perfide können Fragmente von früheren SQL-Server-Installationen sein! Im konkreten Fall stellte sich heraus, dass der SQL-Browser-Dienst einer früheren SQL-Installation trotz de-installieren noch lief und den Port 1433 abhörte. Das verhinderte, dass der neu-installierte SQL-Server-Dienst die Anfrage auf Port 1433 bekam und so die Anfrag immer ins Leere lief!

  • Prüfen Sie deshalb im Task-Manager, ob es Prozesse (Dienste, Programme) gibt, die mit SQL-Server zu tun haben, aber dort nicht sein sollten.
  • Prüfen Sie, ob es im Verzeichnis "C:\Programme\Microsoft SQL Server" Verzeichnisse gibt, die von alten SQL-Server-Installationen stammen:
Verzeichnis Version
80 SQL-Server© 2003
90 SQL-Server© 2005
100 SQL-Server© 2008
110 SQL-Server© 2012
120 SQL-Server© 2014
130 SQL-Server© 2016
140 SQL-Server© 2017
150 SQL-Server© 2019

Zum Testen können Sie ein verdächtiges Verzeichnis umbenennen, den Server neu starten und prüfen, ob das Problem dadurch beseitigt wurde. Wenn ja, benutzen Sie ein Tool, um die Registry aufzuräumen, also z.B. Verweise auf automatisch zu startende Prozesse zu entfernen, die nicht mehr existieren.

Einzelheiten dazu finden Sie hier:

Zugriff auf SQL-Server nicht möglich wegen Überbleibsel

3 Links