Hallo zusammen,

es existiert eine kleine Anwendung die per ADO auf MS-SQL bzw. MS-SQL Express zugreift.
Die Angabe, auf welchen Host zugegriffen wird, wird durch einen Eintrag in einer INI geregelt. Standardmäßig steht dort ein Eintrag wie:

markieren

Code:

Server=Servername\SQLEXPRESS

Diese Anwendung ist bei vielen Kunden im Einsatz und läuft so rund ohne Probleme.
Nun gibt es einen neuen Kunden, der vielfache Probleme hat.
Es gibt inzwischen drei INI-Dateien mit den fogenden Einträgen:

markieren

Code:

Server=Servername.Kunde.com\SQLExpress
Server=\\Servername\SQLExpress
Server=Servername\SQLExpress

Beim Kunden sind öffentliche IPs im Netz verfügbar.

Hat jemand eine Idee, warum dort verschiedene INI-Einträge benötigt werden? Mir gehen langsam die Ideen aus.

Beste Grüße

Das liegt wohl am Netz Deines Kunden. Ich kenne mich mit den Namenskonvetionen nicht besonders gut aus, aber MS hat da verschiedene Möglichkeiten Rechnernamen zu definieren.
Soweit ich weiß gibt es auch Unterschiede, wenn über Domänengrenzen zugegriffen werden muß.
Schau mal in diese Richtung, vielleicht hilft Dir das weiter.

Gruß
K-H

Also ich würde den ConnectionString als UDL-Datei nach aussen legen.
http://www.zerbit.de/artikel/univers...t_gemacht.aspx

Falls es eine UDL-Datei gibt, würde ich diese verwenden und andernfalls
wie bisher weitermachen.
In einer UDL-Datei kannst du die Connection viel besser und bequemer einstellen,
als mit deiner Ini-Datei.

zusammenfalten · markieren

Delphi-Quellcode:

var
  udlfile : string;
begin
  udlfile := ChangeFileExt(ParamStr(0), 'udl'); // Name wie die EXE-Datei nur mit Endung .udl
  if FileExists(udlfile) then
  begin
    ADOConnection1.ConnectionString:='FILE NAME='+udlfile;
  end
  else
  begin
    // Wie bisher die Connection aus Ini-File lesen
  end;
  ADOConnection1.Connected := True;

Hallo und vielen Dank erst einmal für die Antworten!

@p80286: Das vermute ich auch, aber da habe ich keinen Einfluß drauf, kann da also nur Tipps geben. Die Idee wäre, dies irgendwie abzufangen ohne dass es größere Timeouts gibt. Wäre dann nur die Frage, anhand welcher Kriterien man welche Namenskonvetion einbauen sollte ;-(

@sx2008: Auch dieser Ansatz ist interessant, aber meines Erachtens verlagert man das Problem in Richtung der Definition der UDL-Datei. Das Proble der Namensgebung bleibt. Zusätzlich habe ich ann das Problem, dass das im Code fest verdrahtete Passwort wieder in der UDL sichtbar wird, oder?

Besten Dank trotzdem

Zitat von Brinkman:

aber meines Erachtens verlagert man das Problem in Richtung der Definition der UDL-Datei.

Schon, aber genau das ist eine gute Sache.
Man kann einen SQL-Server z.B. auch über die IP-Adresse und Portnr ansprechen:

markieren

Code:

10.4.9.25,1433

Damit erzwingt man quasi dass TCP/IP verwendet wird.
Anderfalls könnte ja auch Named Pipes verwendet werden, wass im gemischten Umgebungen mit Domänen-Controllern und Rechnern, die nicht in der Domäne sind zu Problemen führen kann.

Zitat von Brinkman:

Das Proble der Namensgebung bleibt.

Wo soll da ein Problem sein?
Die Schreibweise "Servername\SQLExpress" ist die Richtige.
Natürlich muss die Namensauflösung für "Servername" funktionieren.
Und TCP/IP muss sowohl Server- als auch Clientseitig aktiviert sein.

Zitat von Brinkman:

dass das im Code fest verdrahtete Passwort wieder in der UDL sichtbar wird

Man braucht/soll das PW in der UDL ja nicht speichern.

markieren

Delphi-Quellcode:

// Anmeldung mit festen PW
ADOConnection1.Open('username', 'festesPasswort');