ODBC Problem ohne Windows Authentifizierung? ERROR [28000] Login failed for user ''

Question

Hallo,

Eine Windows Anwendung wird über den ODBC Treiber SQL Server Native Client 10.0 mit einem SQL Server Express verbunden.

Wenn ich die ODBC Einstellung auf "Windows Authentifizierung" einstelle, klappt alles.

Ich möchte aber eigentlich dafür einen eigenen User (Login) "MyTestUser" nehmen der auch auf dem SQL Server eingerichtet ist.

Der Test in der ODBC Konfiguration funktioniert. Sobald ich aber die Windows Anwendung starte kommt im Error Log die Meldung:

Fehler beim Öffnen: ERROR [28000] [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user ''.

Meine WebAnwendung kann mittels PHP bzw. PDO auch problemlos mit dem User ""MyTestUser"  auf die DB zugreifen.

Ich bin schon zig mal die ODBC Einstellungen durchgegangen und habe wie wild gegoogelt. Mir fällt nichts mehr ein.

Bin für jeden Tipp dankbar was ich noch überprüfen könnte:

ODBC Einrichtung
__________________________________________

Microsoft SQL Server Native Client Version 10.50.1600

Data Source Name: TestDB
Data Source Description:
Server: MyPC\SQLEXPRESS
Use Integrated Security: No
Database: (Default)
Language: (Default)
Data Encryption: No
Trust Server Certificate: No
Multiple Active Result Sets(MARS): No
Translate Character Data: Yes
Log Long Running Queries: Yes
Query Log File: D:\temp\QUERY.LOG
Query Log Time: 30000
Log Driver Statistics: Yes
Statistics File: D:\temp\SQLSERVER_ODBC_STATS.LOG
Use Regional Settings: No
Use ANSI Quoted Identifiers: Yes
Use ANSI Null, Paddings and Warnings: Yes

Answer 1

Hallo,

bist Du Dir auch 100% sicher, dass Deine anderen Anwendung wirklich den MyTestUser verwenden
und nicht doch auf Windows Authentifizierung "zurückfallen".

Überprüfe bitte, ob für die SQL Server Instanz gemischte Authentifizierung zugelassen ist.

Zudem sollte bei der ODBC Konfiguration die Datenbank eingetragen sein, sich auf "Default",
d. h. voreingestellten Datenbank der Anmeldung geht später schon mal schief, wenn das geändert wird.
(auch wenn hier nicht Problemverursacher)

Gruß Elmar

Answer 2

Hi,

zeig doch mal bitte den Code, mit dem Du die Connection öffnest. Der ConnectionString wäre auch wichtig.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 3

Hallo zusammen;
danke für die Hilfe.
<<zeig doch mal bitte den Code, mit dem Du die Connection öffnest. Der ConnectionString wäre auch wichtig.

ja das ist mein Problem weil die Windows Anwendung mein Kollege programmiert. Ich kann ihn event. mal nochmals ansprechen.

Gruss
Hans

Answer 4

Hallo Elmar,

<<Überprüfe bitte, ob für die SQL Server Instanz gemischte Authentifizierung zugelassen ist.

Ja das ist es definitiv. Habe ich schon kontrolliert. Wurde schon beim Server Installation so eingestellt.

Gruss

Hans

Answer 5

Hi,

ja das ist mein Problem weil die Windows Anwendung mein Kollege programmiert.

dann soll dein Kollege den Code und den ConnectionString bereitstellen. Sinnvoller wäre es aber, wenn er selbst sich um das Problem kümmert, wenn er doch der Entwickler ist.

Ich kann ihn event. mal nochmals ansprechen.

Evtl.? Wie willst Du es denn sonst machen? Wenn es nicht funktioniert, muss man wahrscheinlich "irgendwo irgendwas" ändern. Ohne zu wissen, was eure Anwendung da eigentlich macht, kann man das aber nicht wissen.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 6

Hallo zusammen,

So habe die Lösung nun gefunden. (oder zumindest das Problem beheben können)

Ich habe es nun anstatt dem SQL Server Native Client 10 mit dem ODBC Treiber "SQL Server" von Microsoft versucht.

Hier gibt es eine Schaltfläche "Clientkonfiguration". Hier muss man auf "NamedPipe" einstellen. Und siehe da,

jetzt klappt die Verbindung einwandfrei.

Vielleicht hilft es dem einen oder anderen weiter der ein ähnliches Problem hat.

Gruss

Hans

Answer 7

Hallo Hans,

dann passt etwas bei der Netzwerkkonfiguration nicht - heutzutage sollte TCP/IP als Standard verwendet werden.
Und mit dem alten Treiber fallen diverse Neuerungen flach, so dass das keine wirkliche Alternative ist.

Werfe mal den SQL Server Konfigurationsmanager an und überprüfe die Netzwerkprotokolle.
Aktiviert sein sollte unter SQL Server Netzwerkkonfiguration Shared Memory und TCP/IP.

Dort kannst Du auch die Client-Konfiguration für den Rechner vornehmen
(entspricht der Schaltfläche im alten Treiber, das cliconfg.exe aufruft)
Die Reihenfolge sollte Shared Memory und TCP/IP sein (und dann erst Named Pipes, wenn überhaupt).

Gruß Elmar

Answer 8

Hallo Elmar,

habe deine Antwort erst jetzt entdeckt. Vielen Dank für deine Hilfe und Tipps.
Hmm, ich bin nochmals den SQL Server Konfigurationsmanager durchgegangen. Es sind alle Protokolle aktiviert, auch bei der Client Konfiguration.

Und auch die Reihenfolge ist so wie du beschreibst.
Was mir aufgefallen ist. Im ODBC Treiber "SQL Server" gibt es eine eigene Einstellmöglichkeit wo man sagen kann "TCP" oder "NamedPipe"

Diese Option gibt es bei meinem Native Client 10 nicht. Oder ist dies normal?

Gibt es sonst noch etwas was ich überprüfen kann damit es auch mit dem Native Client 10 funktioniert?

Gruss
Hans

Answer 9

Hallo Hans,

bei älteren Treibern konnte man während der Konfiguration das separate Tool "CliConfg.exe" aufrufen, um das bevorzugte Protokoll festzulegen oder einen Alias zu definieren. Diese Einstellung galt aber nicht nur für den einen ODBC Eintrag, sondern den ganzen Client, deswegen gibt es das bei den neueren Treibern nicht mehr.

Du kannst das Tool aber weiterhin aufrufen, einfach über Start => Ausführen ... und dann CliConfg.exe eingeben.

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 10

Hallo zusammen,

vielen Dank für eure Hilfe und Tipps. Ich werde es mal ausprobieren mit "CliConfg.exe" ob es dann bei mir auch mit dem Native Client geht.

Welchen ODBC Treiber nehmt ihr denn eigentlich immer? Ist der SQL Server Native Client 10 die bessere Wahl?
Ist eigentlich in Windows 7 oder Server 2008 R2 immer der ODBC Treiber "SQL Server" mit dabei?

Gruss und danke

Hans

Answer 11

Hallo Hans,

cliconfg.exe beeinflusst nur den alten Treiber.
Die neuen Treiber werden über den Konfigurationsmanager eingestellt, wie bereits geschrieben.
Hintergrund: Die Daten werden in der Registry abgelegt und verwenden unterschiedliche Zweige.

Und auch schon erwähnt:
Verwenden sollte man den SQL Server Native Client, denn nur dort werden neuere Funktionen unterstützt.
Mit dem alten SQL Server Treiber - entsprechendes gilt für den Ole Db Treiber - wird ein Kompatibiltätsmodus
verwendet, wobei das eine oder andere auf der Strecke bleibt,
siehe Einsatzbedingungen für SQL Server Native Client
(Und Entwickler sollten auch den Rest lesen, sofern sie Dokumentationen lesen ;-))

Der Native Client muss separat installiert werden, da man das Konzept der
Integration mit dem Betriebssystem (was mit MDAC noch verwendet wurde) aufgegeben hat.
Die aktuelle Version ist jeweils in den Feature Packs zu finden, siehe
Microsoft® SQL Server® 2012 Feature Pack

Gruß Elmar