Ich hab da ein komisches Problem und bin recht ratlos:

Der SQL Server ist in einem Cluster, ich bin intern im Netz.
Benutzer ist SQL benutzer, Server ist im Mixed Mode.

MS SQL Server mit Datenbank und Benutzer darauf.
Ich kann das Management Studio starten + mit dem Benutzer auf die DB gehen.
Ich kann osql.exe starten und mit dem benutzer auf die DB gehen.
Ich kann ein UDL anlegen und die Verbindung testen - ok.

Mein Delphi Programm, das via OLEDB geht, kann sich aber nicht connecten:
Server existiert nicht oder kein Zugriff.

Ping geht
telnet ip 1433 bringt nur einen schwarzen Schirm, aber keine Fehlermeldung (bei Port 1432 schon).

Bei einem anderen Server im netzt klappt alles ohne Probleme.

Das hatte ich nich nie + ich vermute, es hat eher was mit Netzwerk-Konfig zu tun.

hat irgendwer eine Idee, was es da hat, oder was ich prüfen könnte?

Danke!

Hallo,
hast du bei beiden Servern den gleichen (ähnliche) Connection String?
Mal statt dem Servernamen die IP probiert?
Firewall mal aus?
Telnet geht dem funktionierenden Rechner?

Mixed-Mode, das war doch diese Nummer mit Domain-Nutzer und/Oder SQL-Nutzer?
Damit hatte ich auch schon zwiespältige Erfahrungen gemacht. Wenn ich das Logon nur über den SQL-Nutzer gemacht habe ging es eigentlich immer.

Gruß
K-H

Ich hab in der Praxis lange nichts mit MSSQL zu tun, aber "Mixedmode" gibt es vermutlich schon seit "ewig", hieß bloß nicht so toll und sagt nichts anderes als dass eine Authentifizierung mit DB User oder mit OS / Domain User möglich ist.

Telnet: Schwarzes Fenster mit nix ist ok, der Port ist offen

Ich würde mal die DSN des Servers oder gleich die IP tracen (tracert.exe) und schauen, wo die hinlaufen*. Könnte kaputtes Routing sein, Pakete kommen an, aber nicht zurück.
Das selber mit dem funktionierenden Server und vergleichen. Bei nicht nachvollziehbaren Unterschieden IT fragen, ob das so sein soll. Heutzutage ist sowas ja gern mal in der Cloud oder bei einem DL und die Anbindung, Bandbreite, Routing, .. vielleicht auch mal ein Griff ins Klo.

* also vielleicht bekommt man ja gleich Timeouts bzw. nicht nachvollziehbare Routenabschnitte, die Sternchen * * * * , das wärs dann schon

Mit IP Adresse statt namen geht es zu einem Server, aber zu einem anderen nicht.
Sind aber beide im selben Subnetz.

Und: Mit einer anderen Anmeldung klappt alles ohne Probleme.

Aber die Kernfrage ist:

Warum kann sich mein Delphiprogramm, wenn ich mit meinem USer angemeldet bin, via OLEDB nicht verbinden, osql.exe bzw Test mit UDL mit denselben Anmeldedaten aber schon? Ein andere user aber schon?

Zitat von TigerLilly:

...USer angemeldet bin, via OLEDB nicht verbinden,
...Ein andere user aber schon?

Also zwei UserIds eine Domain eine DB`- der eine kann sich enloggen, der andere nicht?

frag mal den Admin des Domain-Servers wo die Unterschiede in der Definition (Rechte) sind.

Gruß
K-H

Also die Kernfrage kenne ich von Oracle. Es sind natürlich andere Programme, aber der Effekt sehr ähnlich. Ursache ist ein Setupproblem der Clients. OLEDB ist ja auf den anderen Kram draufgesattelt und dann muss halt irgendwie alles passen. Genauer kann ich es Dir bei MS SQL nicht sagen.
Gern auch problematisch: wenn es "historisch" bereits verschiedene Clientversionen und irgendein Mischmasch mit Express Editionen und (heimlichen) embedded Installationen gibt, also Produkte wo nicht MS draufsteht, aber z.B. eine Express Edition im Bauch ist.

Userdurcheinander:
Ich würde versuchen, reinen Tisch zu machen: 2 neue User in der Domäne und jeweils 2 auf den Servern selbst (DB User). Denen stückweise die Berechtigungen raufsetzen und testen oder nach Möglickeit auch mit einem frischen Rechner testen.

Ja, das wär schön. Aber wie so oft: Ein Live-System + historisch gewachsen + eine überforderte IT.

Ich vermute ja, dass das ein Firewall-Problem ist. Die Delphi-programme sind in der Firewall für meinen User nicht zugelassen. darum funktionieren sie nicht, aber andere programme mit meinem user schon + die Delphi-programme mit einem anderen User auch.

Moin...
Wir verwenden ausschießlich den Native Treiber für MSSSQL. Probiere den mal aus.