| 

.NET C# Java Javascript Exception

1
Servus zusammen!

Ich weiß leider nicht mehr weiter. Ich habe eine ganz komisches Phänomen, welches unregelmäßig und leider nicht nachvollziehbar auftritt.
Unsere Windows-Forms-Applikation liest (wie so viele andere auch :p) Daten aus dem SQL-Server aus. Wir verwenden hierbei jedoch nur ADO:
dbCon = New ADODB.Connection
dbCon.CommandTimeout = 0
dbCon.Provider = "SQLOLEDB.1"


An sich klappt der Zugriff auf die Datenbank reibungslos und sogar recht flott. Leider tritt bei einem unserer Kunden die Meldung im Betreff öfters auf und ich komme nicht drauf wieso.

COMException (0x80040E4D): Fehler bei der Authentifizierung


Es wird im SQL-Server nichts protokolliert, d.h. zum fraglichen Zeitpunkt schlägt weder eine positive noch eine negative LOG-Eintragung auf. Auch der Server verzeichnet nichts im Moment des Fehlers.

Ich weiß leider echt nicht mehr weiter und der Kunde wird langsam etwas stinkig...
Habt ihr Tipps für mich?
News:
18.07.2012
daWastl 277 1 7
daWastl 277 1 7
Welchen Authentifizierungsmechanismus verwendest du? Integrated Security? Kann es sein dass es hier ggf. Probleme beim Zugriff auf den Domain Controller gibt?
puls200 18.07.2012
Wir verwenden hierbei den gemischten SQL-Anmeldemodus und melden uns dazu mit SQL-eigenen Benutzern an.

[code]
dbCon.Properties("User ID").Value = meinBenutzer
dbCon.Properties("Password").Value = meinPasswort

[/code]
daWastl 18.07.2012
Ganz sicher Ado und OLEDB? Die OLEDB Syntax zur Angabe von Benutzer und Passwort ist aber UID und PWD und nicht User ID und Password! Dies ist nur bei einer SQLConnection und nicht bei einer OLE DB Connection korrekt.

Provider=SQLNCLI10;Server=myServerAddress;Database=myDataBase;Uid=myUsername; Pwd=myPassword;
JEwen 18.07.2012
wenn das verkehrt wäre würde es wahrscheinlich nie funktionieren..
puls200 18.07.2012
Na ja, auf meinem Entwicklungsrechner hat schon viel funktioniert und beim Kunden dann halt nicht. Fakt ist halt, dass die Dokumentation zu Connectionstrings es so beschreibt. OLE DB = UID und PWD.
JEwen 18.07.2012
Kenn ich :) Er schreibt dass es eben meistens klappt und *manchmal* nicht, das klingt für mich immer ein bisschen nach Netzwerk..
puls200 18.07.2012
Die Software ist ungefähr bei 6000 Kunden so im Einsatz und läuft dort auch stabil - Leider nur bei diesem einen Kunden macht sie Probleme. Dabei ist es so, dass sie auch dort pauschal funktioniert. Nur leider treten eben sporadisch die oben genannten COM-Exceptions auf. Wir reden hier von 50000 Anmeldungen am SQL-Server pro Woche, die funktionieren und 10x kommt dieser Fehler zu Stande
daWastl 18.07.2012
Das könnte natürlich sein, dass der Kunde netzwerkprobleme hat. Ich hatte das mit dem UID/PWD ja auch nur geschrieben, weil beim googeln nach 0x80040E4D eben genau von Microsoft so ein Artikel erscheint. UID /PWD bei OLEDB zu verwenden! Allerdings im Zusammenhang mit ASP.NET und Sessions. Er verwendet ja Windows Forms.
JEwen 18.07.2012
An das haben wir auch schon gedacht. Der Zugriff an der Stelle auf den SQL-Server läuft über eine IP-Adresse. Namensauflösung kann ich daher bereits ausschließen. Aber sowas in die Richtung muss es sein. Mich irritiert nur, dass es so sporadisch passiert und auch immer nur in ganz kleinen Zeitfenstern. Die nächste Verbindung klappt in der Regel dann schon wieder und die kommt wenige (Milli-)Sekunden später...
Habt ihr ne Idee, wie ich das Netzwerkproblem testen und damit bestätigen oder ausschließen kann?
daWastl 18.07.2012
Wenn es ein Netzwerkproblem ist, dann ist es aber komisch, dass es immer nur beim Verbindungsaufbau passiert. Es müssten doch dann sporadisch auch Fehler beim Abfragen der DB auftreten usw. Wenn im SQL Serverlog kein Logeitrag erfolgt ist, wie sieht es in den Ereignisprotokollen von Windows aus? Auch nichts? Wobei es ja der Server selbst sein kann, wie auch der Client.Ist es immer derselbe PC (Client)?
JEwen 18.07.2012
japp... -.- ist leider derselbe PC - Es handelt sich hierbei um einen Terminalserver auf dem auch gleichzeitig der SQL-Server läuft. Leider habe ich auch nur auf diesem System Zugriff auf die Programmspezifischen Protokolldatei in der Fehler geloggt wird. Im Eventlog ist leider auch nix zu finden (wäre ja sonst auch zu einfach :p)
daWastl 18.07.2012
Ein Terminalserver auf dem gleichzeitig der SQL Server läuft! Mir sträuben sich die Haare!!! Du hast gerade die Möglichkeiten der Ursache vervielfacht!
JEwen 18.07.2012
Wenn die connection stehen bleibt dürfte auch alles weitere funktionieren. Kannst du nicht einfach einen try/catch Wrapper um den Verbindungsaufbau herumbauen, der den Zugriff bei Scheitern ein paarmal wiederholt? Hack, aber vllt. machts deinen Kunden schon glücklich.
puls200 18.07.2012
Ja sowas haben wir jetzt angestellt - ist zwar alles andere als schön und sinnvoll aber was will man machen...
Ich finde es ja einfach nur urkomisch, warum so gar keine Verbindung zu Stande kommt und auch nirgendwas geloggt wird...
daWastl 18.07.2012