Discussion:
ODBC Zugriff auf SQL Server
(zu alt für eine Antwort)
Franz Leu
2008-04-01 15:17:22 UTC
Permalink
Hallo

Ich versuche vom Client aus mit osql ein sqlscript anzuwerfen und bekomme folgende Fehlermeldung auf dem Client:

[ODBC Driver Manager] Der Datenquellenname wurde nicht gefunden, und es wurde
kein Standardtreiber angegeben

Wenn ich dasselbe Batchfile auf dem Server ausführe funktioniert das wunderbar. Irgendwas an der ODBC Verbindnung zu Server scheint
nicht zu klappen. Auf dem Client habe ich den Server im ODBC-Quellenadministrator unter Benutzer-DSN eingetragen.

Weiss jemand was ich falsch mache?
Vielen Dank
Franz
Elmar Boye
2008-04-01 15:58:36 UTC
Permalink
Hallo Franz,
Post by Franz Leu
Ich versuche vom Client aus mit osql ein sqlscript anzuwerfen und
[ODBC Driver Manager] Der Datenquellenname wurde nicht gefunden, und es
wurde kein Standardtreiber angegeben
Wenn ich dasselbe Batchfile auf dem Server ausführe funktioniert das
wunderbar. Irgendwas an der ODBC Verbindnung zu Server scheint nicht zu
klappen. Auf dem Client habe ich den Server im ODBC-Quellenadministrator
unter Benutzer-DSN eingetragen.
Wenn Du eine DSN verwendet willst, so müßte dort -D Datenquelle
verwendet werden.
Üblicher (weil ohne DSN möglch) wäre -S Server\Instanz -d Datenbank
Mit osql -L kannst Du zudem testen, ob die Instanz überhaupt
gefunden werden kann (wichtig bei benannten Instanzen)

Beachte, dass die Optionen Groß-/Kleinschreibung unterscheiden.
Ggf. zeige mal die Befehlszeile.

Gruß Elmar
Franz Leu
2008-04-01 16:07:29 UTC
Permalink
Post by Elmar Boye
Wenn Du eine DSN verwendet willst, so müßte dort -D Datenquelle
verwendet werden.
Üblicher (weil ohne DSN möglch) wäre -S Server\Instanz -d Datenbank
Aufruf:
osql.exe -E -SSERVER1 -iP:\CAD\Call_SQL_Import.sql
->funktioniert direkt auf dem Server
Post by Elmar Boye
Mit osql -L kannst Du zudem testen, ob die Instanz überhaupt
gefunden werden kann (wichtig bei benannten Instanzen)
Das ergibt:
P:\CAD>osql -L
[ODBC Driver Manager] Der Datenquellenname wurde nicht gefunden, und es wurde
kein Standardtreiber angegeben
[ODBC Driver Manager] Die Verbindung ist nicht geöffnet


Franz
Elmar Boye
2008-04-01 16:48:14 UTC
Permalink
Hallo Franz,
Post by Franz Leu
osql.exe -E -SSERVER1 -iP:\CAD\Call_SQL_Import.sql
->funktioniert direkt auf dem Server
Post by Elmar Boye
Mit osql -L kannst Du zudem testen, ob die Instanz überhaupt
gefunden werden kann (wichtig bei benannten Instanzen)
P:\CAD>osql -L
[ODBC Driver Manager] Der Datenquellenname wurde nicht gefunden, und es
wurde kein Standardtreiber angegeben
[ODBC Driver Manager] Die Verbindung ist nicht geöffnet
Da schon beim Auflisten scheitert, scheint da etwas kaputt zu sein
Folgende Fragen:
- Welche SQL Server Version? (Falls SQL Server 2005: Probiere sqlcmd.exe)
- Welches Betriebssystem hat der Client-Rechner?
- Welche Version von SQLSRV32.DLL ist installiert
(zu finden in der ODBC Verwaltung -> Treiber)

Versuche zudem eine System-DSN (nicht Benutzer DSN) anzulegen
zu testen, überprüfe dabei auch die Client-Konfiguration, ob
das richtige Protokoll (wie am Server, üblicherweise TCP/IP
und Port - normalerweise 1433) konfiguriert ist.

Prüfe auch, ob evtl. mehr als eine SQLSRV32.DLL auf dem System ist
(es sollte nur eine im SYSTEM32 geben).

Gruß Elmar
Franz Leu
2008-04-02 07:23:20 UTC
Permalink
Post by Elmar Boye
Da schon beim Auflisten scheitert, scheint da etwas kaputt zu sein
- Welche SQL Server Version? (Falls SQL Server 2005: Probiere sqlcmd.exe)
SQL2005 Express (Bestandteil von SBS2003 R2) (fully patched)
Der Aufruf findet ja auf dem lokalen PC statt wo kein SQL installiert ist. Mit osql geht das wenn man auf einem share osql.exe
osql.rll plaziert. Diese können dann von jedem PC aus direkt aufgerufen werden - ohne Installation. Mit sqlcmd.exe ist eine lokale
installation erfoderlich.
Post by Elmar Boye
- Welches Betriebssystem hat der Client-Rechner?
Windows XP SP2 (fully patched)
Post by Elmar Boye
- Welche Version von SQLSRV32.DLL ist installiert
(zu finden in der ODBC Verwaltung -> Treiber)
2000.85.1117.00
Post by Elmar Boye
Versuche zudem eine System-DSN (nicht Benutzer DSN) anzulegen
zu testen, überprüfe dabei auch die Client-Konfiguration, ob
das richtige Protokoll (wie am Server, üblicherweise TCP/IP
und Port - normalerweise 1433) konfiguriert ist.
OK, auf System DSN umgestellt.
TCP/IP, Port automatisch ist ausgewählt.
Post by Elmar Boye
Prüfe auch, ob evtl. mehr als eine SQLSRV32.DLL auf dem System ist
(es sollte nur eine im SYSTEM32 geben).
Nur die eine.

Auch wenn die Listung nicht geht, mit deinen Tips habe ich es zumindest mal dazugebracht das SQL script auszuführen. Um es vom
Client aus zu starten mussten ein paar sachen geändert werden:

osql.exe -Usa -P***** -DSERVER1 -iP:\CAD\Call_SQL_Import.sql

-D anstelle von -S
-E scheint nicht zu gehen, nur muss ich so das Passwort in klartext hinschreiben ... kann ja auch nicht sein. Gibts da eine Lösung?

Habe ich den falschen Weg eingeschlagen?
Am Ende soll das SQL script auf dem SQL Server von einem VBScript von jedem PC aus angestossen werden können. Das VBScript kopiert
ein paar files und soll nacher das SQL script anstossen. Das VBScript habe ich einfach auf einem share plaziert, zusammen mit den
osql dateien.
Macht man das anders besser?

Vielen Dank für die Hilfe so far.
Franz
Elmar Boye
2008-04-02 07:42:46 UTC
Permalink
Post by Franz Leu
Post by Elmar Boye
Da schon beim Auflisten scheitert, scheint da etwas kaputt zu sein
- Welche SQL Server Version? (Falls SQL Server 2005: Probiere sqlcmd.exe)
SQL2005 Express (Bestandteil von SBS2003 R2) (fully patched)
Der Aufruf findet ja auf dem lokalen PC statt wo kein SQL installiert
ist.
Mit osql geht das wenn man auf einem share osql.exe osql.rll
plaziert. Diese können dann von jedem PC aus direkt aufgerufen werden -
ohne Installation. Mit sqlcmd.exe ist eine lokale installation erfoderlich.
Wenn Du kein Management Studio Express installieren willst,
kannst Du auf dem Client SqlCmd.exe aus dem Feature Pack installieren:
http://www.microsoft.com/downloads/details.aspx?FamilyID=50b97994-8453-4998-8226-fa42ec403d17&displaylang=de

das ist der aktuellere Ersatz für osql und besser als
eine handgestrickte Variante ;-)
Post by Franz Leu
Auch wenn die Listung nicht geht,
Überprüfe auch ob der Browser Dienst auf dem Server läuft
(auch wenn der für eine Standardinstanz nicht unbedingt notwendig ist)
Post by Franz Leu
mit deinen Tips habe ich es zumindest
mal dazugebracht das SQL script auszuführen. Um es vom Client aus zu
osql.exe -Usa -P***** -DSERVER1 -iP:\CAD\Call_SQL_Import.sql
-D anstelle von -S
-E scheint nicht zu gehen, nur muss ich so das Passwort in klartext
hinschreiben ... kann ja auch nicht sein.
Bei Standardsicherheit ist das so - und die sollte normalerweise abgeschaltet
sein. Deswegen grundsätzlich für "sa" ein anderes Kennwort nutzen, als für
den Administrator und andere wichtige Konten
Post by Franz Leu
Gibts da eine Lösung?
Ist der Client Rechner in der gleichen Domäne wie der Server?
Und hast Du Dich mit einem Domänen-Konto angemeldet?
Nur dann und wenn das Konto im SQL Server hinterlegt ist,
funktioniert -E (vertraute Verbindung)
Und -S sucht den Rechner ebenso zunächst in der Domäne.

Seltsam sind allerdings immer noch die harschen Fehlermeldungen,
denn eine fehlerhafte Anmeldung wird normalerweise anders quittiert.
Einzige Erklärung wäre Übertragung osql.

Gruß Elmar
Franz Leu
2008-04-02 08:55:44 UTC
Permalink
Post by Elmar Boye
Überprüfe auch ob der Browser Dienst auf dem Server läuft
(auch wenn der für eine Standardinstanz nicht unbedingt notwendig ist)
Läuft
Post by Elmar Boye
Bei Standardsicherheit ist das so - und die sollte normalerweise abgeschaltet
sein. Deswegen grundsätzlich für "sa" ein anderes Kennwort nutzen, als für
den Administrator und andere wichtige Konten
Sorry, aber das verstehe ich nicht ganz: Der SQL Server hat Standardsetup und an den Sicherheitseinstellungen wurde nichts gedreht.
Ist denn nun Standarsicherheit aktiv oder nicht?
Was ermöglicht/verunmöglicht mir die Standardsicherheit in diesem Zusammenhang?
sa hat ein anderes Kennwort welches nur da verwendet wird.
Post by Elmar Boye
Ist der Client Rechner in der gleichen Domäne wie der Server?
Ja
Post by Elmar Boye
Und hast Du Dich mit einem Domänen-Konto angemeldet?
Ja
Post by Elmar Boye
Nur dann und wenn das Konto im SQL Server hinterlegt ist,
funktioniert -E (vertraute Verbindung)
Also im SQL Server zusätzlich, AD reicht nicht? Kann ich da auch eine ganze (bereis existierende) Gruppe zulassen?

Vielen Dank
Franz
Jürgen Volke
2008-04-02 09:45:00 UTC
Permalink
Hallo Franz
Post by Franz Leu
Post by Elmar Boye
Überprüfe auch ob der Browser Dienst auf dem Server läuft
(auch wenn der für eine Standardinstanz nicht unbedingt notwendig ist)
Läuft
Post by Elmar Boye
Bei Standardsicherheit ist das so - und die sollte normalerweise abgeschaltet
sein. Deswegen grundsätzlich für "sa" ein anderes Kennwort nutzen, als für
den Administrator und andere wichtige Konten
Sorry, aber das verstehe ich nicht ganz: Der SQL Server hat Standardsetup
und an den Sicherheitseinstellungen wurde nichts gedreht. Ist denn nun
Standarsicherheit aktiv oder nicht?
Was ermöglicht/verunmöglicht mir die Standardsicherheit in diesem Zusammenhang?
sa hat ein anderes Kennwort welches nur da verwendet wird.
Post by Elmar Boye
Ist der Client Rechner in der gleichen Domäne wie der Server?
Ja
Post by Elmar Boye
Und hast Du Dich mit einem Domänen-Konto angemeldet?
Ja
Post by Elmar Boye
Nur dann und wenn das Konto im SQL Server hinterlegt ist,
funktioniert -E (vertraute Verbindung)
Also im SQL Server zusätzlich, AD reicht nicht? Kann ich da auch eine
ganze (bereis existierende) Gruppe zulassen?
ja auch im SQL-Server muß der User/Gruppe als Benutzer angelegt werden.
Ganze Gruppe ist möglich

Gruß Jürgen
Franz Leu
2008-04-02 09:50:34 UTC
Permalink
Post by Jürgen Volke
ja auch im SQL-Server muß der User/Gruppe als Benutzer angelegt werden.
Ganze Gruppe ist möglich
Vielen Dank für deine geduldige Hilfe!
Es funtioniert nun alles wie gewünscht :-)

Franz
Franz Leu
2008-04-02 10:01:37 UTC
Permalink
Post by Franz Leu
Vielen Dank für deine geduldige Hilfe!
Es funtioniert nun alles wie gewünscht :-)
Franz
meinte natürlich eure Hilfe ;-)
Franz Leu
2008-04-02 13:53:57 UTC
Permalink
Doch noch ne Anschlussfrage:

Kann ich die System-DSN (da komm ich ja nicht drumrum) zentral 'verteilen', via GPO oder so?
Ist das einfach irgendwo ein Registryeintrag?

Danke
Franz
Elmar Boye
2008-04-02 14:36:17 UTC
Permalink
Hallo Franz,
Post by Franz Leu
Kann ich die System-DSN (da komm ich ja nicht drumrum) zentral
'verteilen', via GPO oder so?
Ist das einfach irgendwo ein Registryeintrag?
Eine System-DSN wird in der Registry unter
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
abgestellt.

Zudem gibts im MDAC gibts eine Hilfsprogramm odbcconf.exe, das
auch für die Einrichtung der Standardeinträge verwendet wird.
odbcconf /? verrät Dir die Parameter.

Gruß Elmar
Franz Leu
2008-04-02 15:02:14 UTC
Permalink
Post by Elmar Boye
Eine System-DSN wird in der Registry unter
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
abgestellt.
Zudem gibts im MDAC gibts eine Hilfsprogramm odbcconf.exe, das
auch für die Einrichtung der Standardeinträge verwendet wird.
odbcconf /? verrät Dir die Parameter.
Gruß Elmar
STAUN!
Gelesen, probiert ... mit odbcconf funktioniert es wunderbar.
Vielen Dank :-)
Franz

Loading...