Fehlerhafter SQL-ConnectionString

[Brinkman]

Hallo zusammen,

habe gestern ein Problem gestellt bekommen, was ich nicht einordnen kann und auch noch nie gesehen habe.
Eine Anwendung greift per ADO auf MSSQL zu. Der Servername im ConnectionString lautet SERVER bzw. beim Express SERVER\SQLEXPRESS. So weit so gut. Nun gibt es einen Kunden, der mit verschiedenen Clients diese Anwendung nutzen kann nur bei einem Client wird die Verbinsung nicht aufgebaut, da "der Server nicht gefunden wurde oder das Passwort falsch sei".
Dieser Kunde arbeitet mit SQL 2008 Express und auf diesem Client ist VISTA 32 SP1 installiert. Ändert man aber den ConnectionString so, dass dort \\SERVER\SQLEXPRESS als Servername steht, klappt alles einwandfrei. Nun aber können die anderen Clients nicht auf die Anwendugn zugreifen. Andere Clients mit VISTA 32 SP1 arbeiten jedoch problemlos mit der Standardeinstellung.

Woran kannn es eventuell liegen?

Beste Grüße
Brinkman

[jobo]

Ich vermute mal, Dein Programm erlaubt nur einen einheitlichen Connectionstring? Das zu flexibilisieren wäre ein Ansatz, fänd ich sowieso empfehlenswert.
Das Problem kenne ich nicht, aber ich würde als verdächtig erstmal die ADO DB Treiber / MDAC auf den Maschinen auf Versionsstände abgleichen. Vista SP1 an sich hat ja nichts mit der DB Client Version zu tun. Die kann schon durch unterschiedliche Office Installationen abweichen.

[shmia]

Es gibt ja 3 verschiedene OLE-DB Provider für MS SQL-Server
1. Micrsoft OLE DB Provider for SQL Server (SQL Server 7/2000)
2. SQL Native Client (SQL Server 2005)
3. SQL Server Native Client 10.0 (SQL Server 2008)
Verwendest du überall den SQL Server Native Client 10.0?

[Bernhard Geyer]

Zitat von jobo:

Ich vermute mal, Dein Programm erlaubt nur einen einheitlichen Connectionstring? Das zu flexibilisieren wäre ein Ansatz, fänd ich sowieso empfehlenswert.

Würde maximal wiedersprechen. Wieso sollte für eine Serverinstallation multiple Connectionstring-angaben nötig seim um in einem Firmen-Intranet den gleichen Server zu erreichen?

Zitat von jobo:

Das Problem kenne ich nicht, aber ich würde als verdächtig erstmal die ADO DB Treiber / MDAC auf den Maschinen auf Versionsstände abgleichen. Vista SP1 an sich hat ja nichts mit der DB Client Version zu tun. Die kann schon durch unterschiedliche Office Installationen abweichen.

Sollte eigentlich nicht der Fall. Diese Treiber werden eigentlich per Windows/MS-Update aktualisiert.

Die Frage ist aber wieso noch SP1? Vista hat in den ersten Jahren (persönliche Erfahrungen) so einige Netzwerkproblem (Timeouts, Performance). Evtl. liegt ja noch ein Netzwerkfehler vor wenn man noch SP1 am laufen hat.

[Bernhard Geyer]

Zitat von shmia:

Es gibt ja 3 verschiedene OLE-DB Provider für MS SQL-Server
1. Micrsoft OLE DB Provider for SQL Server (SQL Server 7/2000)
2. SQL Native Client (SQL Server 2005)
3. SQL Server Native Client 10.0 (SQL Server 2008)
Verwendest du überall den SQL Server Native Client 10.0?

Sollte eigentlich kein Problem sein. Greifen auf SQL 7-2008R2 mit dem MS OLE DB-Treiber zu und haben bisher an dieser Stelle der Namensaufösung keine Problem (wenn der Server richtig konfiguriert ist).

[jobo]

Zitat von Bernhard Geyer:

Zitat von jobo:

Ich vermute mal, Dein Programm erlaubt nur einen einheitlichen Connectionstring? Das zu flexibilisieren wäre ein Ansatz, fänd ich sowieso empfehlenswert.

Würde maximal wiedersprechen. Wieso sollte für eine Serverinstallation multiple Connectionstring-angaben nötig seim um in einem Firmen-Intranet den gleichen Server zu erreichen?

Zitat von jobo:

Das Problem kenne ich nicht, aber ich würde als verdächtig erstmal die ADO DB Treiber / MDAC auf den Maschinen auf Versionsstände abgleichen. Vista SP1 an sich hat ja nichts mit der DB Client Version zu tun. Die kann schon durch unterschiedliche Office Installationen abweichen.

Sollte eigentlich nicht der Fall. Diese Treiber werden eigentlich per Windows/MS-Update aktualisiert.

Multiple Connection Strings habe ich lediglich empfohlen. Maximalen Widerspruch find ich da etwas übertrieben. Unsere Kunden setzen bspw. ein Q System ein bzw. arbeiten an mehreren Standorten mit dezentralen und Zentralen DB Systemen. Die Anwendung kann je nach Einstellung aus Registry Vorgaben oder interaktiv verschiedene Server ansprechen.

Treiberversionen sollten in einer idealen Welt möglichst uptodate und identisch sein. Bei MS kenne ich es aber z.B. so, dass unabhängig vom OS (und Servicepack) allein ein Office Update ausreicht, um da in Schieflage zu geraten. Auch das war lediglich ein Hinweis zur Fehlersuche.
Und Windows Update hat bei meinen Systemen keinen direkten Einfluss auf die Aktualität der Komponenten. Ich hab es so eingestellt, dass es nur auf meine Erlaubnis hin installiert. Und ich krieg sofort Puls, wenn ich es mal irgendwo vergessen hab und diese besch... Meldung kommt, dass das System JETZT oder in 10 Sekunden runterfährt.

[Bernhard Geyer]

Zitat von jobo:

Multiple Connection Strings habe ich lediglich empfohlen. Maximalen Widerspruch find ich da etwas übertrieben. Unsere Kunden setzen bspw. ein Q System ein bzw. arbeiten an mehreren Standorten mit dezentralen und Zentralen DB Systemen. Die Anwendung kann je nach Einstellung aus Registry Vorgaben oder interaktiv verschiedene Server ansprechen.

OK. Du hast verschiedene Installationen gemeint. Da stimm ich dir zu. Wir hatten denn falls das mit unterschiedlichen Konfigurationen auf die gleiche DB-Instanz gegangen ist. Und da kannst du dir natürlich vorstellen das man hier flucht wenn man fehler sucht und in zig Konfigurationsdateien nachschauen müsste obwohl es nur eine gültige geben kann.

Zitat von jobo:

Treiberversionen sollten in einer idealen Welt möglichst uptodate und identisch sein. Bei MS kenne ich es aber z.B. so, dass unabhängig vom OS (und Servicepack) allein ein Office Update ausreicht, um da in Schieflage zu geraten. Auch das war lediglich ein Hinweis zur Fehlersuche.

Früher und bei Access mag das noch sehr schwierig gewesen sein. Heutzutage sollte das (wenn Windows-Updates aktive sind - was man empfehlen sollte) das fast nicht mehr auftreten.

[generic]

Sind auf dem Server bzw. auf den Clients die gleich Protokolle aktiviert?
Werden auch wirklich die gleichen Protokolle genutzt?

Bei dem 2000er Server war das mit dem Tool "cliconfg.exe" einzustellen.
Bei den neuen Varianten weiß ich es nicht.
Evtl. nutzt du sogar den "alten" Treiber?

[shmia]

Zitat von Bernhard Geyer:

Zitat von shmia:

...verschiedene OLE-DB Provider für MS SQL-Server...

...Greifen auf SQL 7-2008R2 mit dem MS OLE DB-Treiber zu und haben bisher an dieser Stelle der Namensaufösung keine Problem...

"Normalerweise" kann man mit jedem der 3 Treiber alle SQL Server Versionen 7/2000/2005/2008/2008R2 erreichen.
Dennoch gibt es Unterschiede.
Nach meinen Messungen sind die Native Treiber beim Abrufen grossen Datenmenge bis zu 15% schneller als der "alte OLE-DB Provider".
Es ist einleuchtend, dass der "SQL Server Native Client 10.0" der zusammen mit dem SQL Server 2008 released wurde mit einem 2008R2 besser harmoniert als ein Treiber der schon viele Jahre auf dem Buckel hat.
Treiberintern wird Tabular Data Stream als Protokoll verwendet.
Davon gibt es verschiedene properitäre Varianten und deshalb ist die Wahl des Treiber wichtig.

[Bernhard Geyer]

Zitat von shmia:

"Normalerweise" kann man mit jedem der 3 Treiber alle SQL Server Versionen 7/2000/2005/2008/2008R2 erreichen.
Dennoch gibt es Unterschiede.
Nach meinen Messungen sind die Native Treiber beim Abrufen grossen Datenmenge bis zu 15% schneller als der "alte OLE-DB Provider".
Es ist einleuchtend, dass der "SQL Server Native Client 10.0" der zusammen mit dem SQL Server 2008 released wurde mit einem 2008R2 besser harmoniert als ein Treiber der schon viele Jahre auf dem Buckel hat.
Treiberintern wird Tabular Data Stream als Protokoll verwendet.
Davon gibt es verschiedene properitäre Varianten und deshalb ist die Wahl des Treiber wichtig.

Eigentlich müsst man das für unser Produkt auch mal anschauen. Aber da MS ADO abgekündigt hat und wieder voll auf ODBC setzt werde ich mir das sparen und die Zeit besser in den ODBC-Port investieren (oder warten ob mit MS SQL-Server 2015 dann ADO++ die Wahl ist