ADO und Laufzeitanbindung an den SQL-Server

[Stephan Schneider]

Hallo,

Eine Delphi6-Anwendung soll mittels ADO auf eine MSSQL Server 2000 Datenbank zugreifen. Welcher Weg einer Laufzeitanbindung an den SQL-Server ist erfahrungsgemäß besser (sofern man das Wort besser verwenden kann). Der Name der DB selbst innerhalb des Servers bleibt gleich, die MSSQL-Servernamen unterscheiden sich (Entwicklungsumgebung vs. Laufzeitumgebung).

Welche Eigenschaften von ADOConnection müssen wie (Inhalte, Reihenfolge, usw.) gesetzt werden, um eine reibungslose Laufzeitanbindung zu gewährleisten, unterscheidet man die beiden Fälle<br>
(a) Verwendung einer UDL-Datei<br>
(b) Verbindungsstring dynamisch zusammensetzen (keine UDL-Datei)<br>

(Natürlich wird programmtechnisch der ConnectionString auch bei einer UDL-Datei dynamisch zusammengesetzt)

Gruß<br>
Stephan Schneider

[Andreas Kosch]

Hallo,

prinzipiell spielt es keine Rolle, woher der ConnectionString für die ADO-Verbindung kommt, daher ist UDL-Datei oder direkte Zuweisung an die TADOConnection-Eigenschaft über den Konfigurationsdialog gleichwertig. Eine UDL-Datei ist immer dann sinnvoll, wenn der Endanwender die Verbindungsdaten ändern darf (oder sogar soll).

Generell sollten alle ADO-Objekte einen client-seitigen Cursor verwenden (<b>clUseClient</b>), wenn auf eine Microsoft SQL Server 7/2000-Datenbank zugegriffen wird. In diesem Fall holt sich ADO beim Öffnen der Datenmenge über den sogenannten <i>Firehouse-Cursor</i> (der schnellste Verbindungsweg zwischen SQL Server und Client) alle Daten auf den eigenen Rechner, so dass die Ergebnismenge auf dem SQL Server sofort danach geschlossen werden kann (ohne das davon der Client betroffen ist). Bei einem client-seitigen Cursor spielen die restlichen ADO-Konfigurationen (wie zum Beispiel CursorType) nur eine untergeordnete Rolle. Man muss nur für <b>LockType</b> eine Entscheidung treffen: <br>
a) ltOptimistic, oder <br>
b) ltBatchOptimistic (wenn die Daten im Offline-Modus bearbeitet werden sollen

[Stephan Schneider]

Hallo,

danke für Ihre Antwort. Leider läuft es bei mir nicht ganz so reibungslos.

Ich verwende eine UDL-Datei, die im gleichen Verzeichnis liegt wie die EXE (sollte später auch so sein, oder spielt dass bereits eine Rolle). Zu Beginn wird der ConnectionString wie folgt zusammengesetzt:

<pre>
sUDLFile := ExtractFilePath(Application.ExeName) + ‘DBName.udl’;
if ADOConnection.Connected then ADOConnection.Close;
ADOConnection.ConnectionString := Format(‘FILE NAME = %s’,[sUDLFile]);
ADOConnection.Open;
</pre>

Keine weitere Eigenschaft wird gesetzt. Kopiere ich nun die EXE samt UDL-Datei in ein neues Verzeichnis (=<i>Laufzeitumgebung</i>) und lösche die EXE und die UDL-Datei aus dem alten Verzeichnis (=<i>Entwicklungsumgebung</i>), so ernte ich den Fehler <i>OLE-Fehler 80030002</i>. Der Grund liegt darin, dass sich die UDL-Datei nicht mehr im alten Verzeichnis befindet (kopiere ich sie dorthin zurück, läuft alles wunderbar). Doch genau dies ist ja der Unterschied zwischen Entwicklungsumgebung und Laufzeitumgebung beim Endanwender. Spielen dann auch noch andere Eigenschaften eine Rolle? Oder ist das dynamische Setzen des ConnectionString falsch, so dass der Fehler begründet ist?

Meiner Ansicht nach wird der Endanwender die Verbindungsdaten doch immer ändern müssen bzw. die Möglichkeit angeboten bekommen zumindestens den Servernamen anzugeben (vorausgesetzt der Datenbankname kann beim Endanwender verwendet werden).

Die Möglichkeit, wie sie das Borlandbeispiel ADOTest zeigt (über <pre>EditConnectionString(ADOCOnnection)</pre>) besteht natürlich auch noch, mich würde aber die reibungslose Implementierung via UDL-Datei interessieren.

Vielen Dank im vorau

[Gerhard Duerr]

hallo stephan,

ich binde zur laufzeit udl-dateien (oracle + mssql) wie folgt ein:

swConnStr := 'FILE NAME=' + DataLinkDir + cmbUDL.Text;
// Auswahl ob oracle oder mssql

mein DataLinkDir zeigt auf
..\Programme\Gemeinsame Dateien\System\OLE DB\Datalinks

Der Inhalt meiner udl-datei sieht wie folgt aus:

[oledb]
; Everything after this line is an OLE DB initstring
Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;Initial Catalog= datenbankname;Data Source=servername

in der ADODB.pas ist DataLink hinterlegt. event. kann man den
verbiege

[Stephan Schneider]

Hallo Gerhard,

danke für Deine Antwort.

Und wie ist es, wenn Deine Anwendung weitergegeben wird. Greift ein Client (Rechner1) durch Deine Anwendung auf den SQL-Server (Rechner2) zu, dann ist nicht notwendigerweise dieses Verzeichnis auf dem Rechner1 vorhanden. Die Verwendung einer UDL-Datei ist doch quasi ein Pendant zum BDE-Alias, wobei die BDE auf jedem Client-Rechner installiert sein muss. Aber nicht der MSSQL-Server.

Stepha

[Andreas Kosch]

Hallo,

das Problem kann nur dann auftreten, wenn man sich nicht an die von Microsoft aufgestellten Spielregeln hält. Der "richtige" Weg würde so aussehen: <br>
1. Programm ermittelt über <b>DataLinkDir</b> (Unit ADODB.pas) das Verzeichnis, in dem die UDL-Datei vom Betriebssystem verwaltet werden. <br>
2. Alle eigenen UDLs landen in diesem Verzeichnis <br>
4. Beim Programmstart wird ebenfalls diese Funktion verwendet, um das Verzeichnis zu bestimmen, indem die UDLs gesucht werden müssen.

P.S: ADO (genauer gesagt OLE DB) verwendet einen Datenbankverbindungs-Pool je Prozess. Somit <b>muss</b> Delphi geschlossen und neu gestartet werden, damit eine "alte" ADO-Verbindung die neue Konfiguration verwendet.
&#10