SQL DB in der Anwendung nicht erreichbar, aber ODBC-Verbindung funktioniert

[BSChris 13]

Hallo,

 

zum testen habe eine SQL-Datenbank von einem SQL-Server 2014 auf einen SQL-Server 2019 wiederhergestellt. Die Datenbank selbst ist auf dem Kompatiblitätslevel 100 (SQL 2008).

Den lokalen User der für die Datenbank genutzt wird, habe ich mit migriert und hat auch die gleichen Rollen wie zuvor auf dem alten SQL-Server auch.

Auf einem Session Host habe ich die ODBC-Verbindung zur Testdatenbank hergestellt. Die lässt sich mit dem lokalen User auch verbinden.

Doch in der Anwendung selbst, die ebenfalls auf dem Session Host gestartet wird bekomme ich folgendes:

Nach dem Wort User wird hier im Bild der User der ODBC-Verbindung angezeigt.

 

Wenn der ODBC-Test Erfolgreich war, sollte es doch eigentlich auch funktioneiren oder?

Auf beiden SQL-Servern sind die gleichen Einstellungen bzw. Berechtigungen, von daher bin ich etwas irritiert.

Im Grunde gibt es nur einen Unterscheid zwischen den Datenbanken, und das ist der Server also das OS und die SQL-Version.

Vielleicht weiss jemand einen Rat.

 

Grüße Chris

bearbeitet 11. Juni von BSChris

[Sunny61 798]

Evtl. ist hier der verwendete ODBC Treiber nicht mehr passend zum SQL Server. Kannst Du dich testweise auf dem SQL Server im SQL Server Management Studio mit dem User anmelden? TCP Port 1433 ist auf dem SQL Server eingehend freigegeben? Wenn die Instanz auf Port 1433 läuft.

[BSChris 13]

Hi Sunny61,

 

ja das funktioniert, ich kann mich im SSMS mit dem lokalen Benutzer anmelden.

bearbeitet 11. Juni von BSChris

[BSChris 13]

Werde mal eine aktuellen Treiber auf den Session Host installieren und danach berichten.

[MDD 12]

Hallo CHris

Für mich schaut’s so aus als wäre der User noch nicht richtig zugewiesen.

Schon sp_change_users_login versucht?

Wenn ich mich richtig entsinne ist das die Fehlernummer die bei auftritt wenn man zuerst den Benutzer hat und anschließend von einem anderen Server die Rücksicherung macht.

.

 

[BSChris 13]

Hi MDD,

 

tatsächlich habe ich 

EXECUTE sp_change_users_login @action = 'Report'

mal ausgeführt und der User wurde mir angezeigt. Anschließend habe ich folgendes ausgeführt:

EXECUTE sp_change_users_login @action = 'Auto_Fix',
                              @userNamePattern = 'user',
                              @password = 'password'

Danach kam nur noch die Message, dass ich ein anderes Passwort nehmen muss, Aufgrund der Password Policy vom Server.

Gemacht getan!

Auf dem Session Host die ODBC-Verbindung angepasst (Passwort), allerdings erhalte ich in der Applikation beim auswählen der Datenbank die gleiche Fehlermeldung.

Ich habe noch nicht den aktuellen ODBC Treiber für den SQL Server installiert. Aber wenn der ODBC-Test Erfolgreich ist, spielt das doch eigentlich keine Rolle mehr oder?

 

Gruß

Chris

bearbeitet 11. Juni von BSChris

[Sunny61 798]

So etwas ähnliches hatten wir kürzlich aus, es gab denn ein Update der Anwendung, natürlich war es eine andere Version des ODBC Treibers. Probier einfach mehrere aus, ansonsten den Support der Anwendung ins Boot holen.

[t-sql 17]

Was steht denn im Errorlog des SQL Servers drin? Wenn sich der User nicht anmelden kann steht drin warum. Und um Logins von einem SQL Server zum anderen zu transportieren gibt es eine Stored Procedure von Microsoft (Transfer logins and passwords between instances - SQL Server | Microsoft Learn)

bearbeitet 12. Juni von t-sql

[BSChris 13]

Hallo,

 

nehmt es mir nicht übel, dass ich bisher noch nicht von mir gegeben habe, ich melde mich Morgen,

da ich gerade etwas unter Strom stehe :)

Das steht im EventLog des Neuen SQL-Servers

CLIENT: ist der Session Host. Es deutet ja auf dasPasswort hin, nur warum funktioneirt dann die ODBC-Verbindung?

Wie gesagt ich melde mich Morgen.

Vielen Dank euch

 

Gruß

Chris

[Sunny61 798]

vor 1 Stunde schrieb BSChris:

Es deutet ja auf dasPasswort hin, nur warum funktioneirt dann die ODBC-Verbindung?

AFAIK wird dabei nur eine Verbindung zum SQL Server getestet, nicht die Anmeldung an der Datenbank.

[t-sql 17]

vor 3 Minuten schrieb Sunny61:

AFAIK wird dabei nur eine Verbindung zum SQL Server getestet, nicht die Anmeldung an der Datenbank.

Dann wäre die Meldung im Errorlog eine andere.

[Sunny61 798]

vor 1 Stunde schrieb t-sql:

Dann wäre die Meldung im Errorlog eine andere.

Der TO hat sich sicher auf diese Meldung bezogen:

 

Und er konnte sich auch mit dem Benutzer am SSMS anmelden:

 

Aber der Zugriff auf die DB hat, warum auch immer, nicht funktioniert.

[t-sql 17]

vor einer Stunde schrieb Sunny61:

Der TO hat sich sicher auf diese Meldung bezogen:

 

Aber der Zugriff auf die DB hat, warum auch immer, nicht funktioniert.

Ja, stimmt. Aber wenn der User keinen Zugriff auf die Datenbank hätte, sich aber anmelden dürfte steht das "Login failed for user 'MY-PC\MyName'. Reason: Failed to open the explicitly specified database. [CLIENT: ]" im Errorlog und nicht das das falsche Passwort bei der Application genutzt wird.

[Sunny61 798]

Tja, ich weiß es nicht was der TO genau gemacht hat, warten wir auf seine Rückmeldung. ;)

[BSChris 13]

Hallo,

 

vielen Dank für eure Unterstützung. Das Problem konnte ich mit einem externen Dienstleister lösen.

Folgendes wurde durchgeführt.

• Im Programmverzeichnis der Applikation, wird bei der ersten Anmeldung für die Datenbank eine sql_password.dat datei erstellt. Ein normaler Terminal User hat aber keine Rechte, diese Datei anzulegen. Daher musste die Applikation extra als Administrator ausgeführt werden, damit diese Datei erstellt werden kann. Dieses muss nur einmalig von einem Administrator erstellt werden, der normale Terminal User zieht sich diese nach Anmeldung automatisch bzw. nutzt diese mit.
• In den ODBC-Verbindungen sind mehrere Datenbanken hinterlegt und ich muss die ODBC-Verbindungen folgender maßen benennen.
  • db_sql_server_1
  • db_sql_server_2
  • db_sql_server_3
    usw...
    Ich habe die 3 verwendet und ausgerechnet mit der 3 hat die Applikation ein Problem weshalb ich dann die 4 nehmen musste.

Im Grunde diese beiden Sachen haben für das scheitern gesorgt.

Das war es im grunde genommen, einen neuen ODBC-Treiber hatte ich getestet aaber gab mir die gleiche fehlermeldung.

 

Ich wusste selbst nicht, das dies ein so Applikations lastiges Thema ist. Dennoch vielen Dank für eure Denkanstöße und eure Zeit.

 

Gruß

Chris