ADO/ODBC

[Macher]

Hallo,

gibt es eine Möglichkeit den Datenbanktyp zuermitteln, also ob es sich z.B. um eine Orcale oder SQL Server Datenbank handelt. Ich greife per ADOConnection auf ein ODBC Filedsn welches die Logindaten enthält.

[mkinzler]

In der dsn steht auch der zu verwendende Treiber drin.

[Edit: dsn war natürlich gemeint]

[Macher]

Zitat von mkinzler:

In der dnc steht auch der zu verwendende Treiber drin.

Das sollte die letzte Lösung sein die ich umsetzen wollte. Wäre gut wenn ich es direkt über die ADOConnection ermittlen könnte.

[jensw_2000]

Nachdem die ADOConnection geöffnet ist, kannst du TAdoConnection.Provider auslesen.
Dieser Wert wird nach dem Öffnen der Connection automatisch aktualisiert.



Schöne Grüße,
Jens

[Macher]

Zitat von jensw_2000:

Nachdem die ADOConnection geöffnet ist, kannst du TAdoConnection.Provider auslesen.
Dieser Wert wird nach dem Öffnen der Connection automatisch aktualisiert.



Schöne Grüße,
Jens

Dadurch das ich über die ODBC, und nicht direkt auf die einzeln DBs zugreife bleibt der Provider immer gleich "MSDASQL.1" hmmm...

Bei der BDE, die ich Vorher benutzt hatte, konnte man mit der procedure "Check" den Typ ermitteln sowas ähnliches suche ich jetzt halt für ADO

[shmia]

Zitat von Macher:

Dadurch das ich über die ODBC, und nicht direkt auf die einzeln DBs zugreife bleibt der Provider immer gleich "MSDASQL.1" hmmm...

Es ist ein Fehler, den Umweg über ODBC zu nehmen, wenn ein OLE-DB Provider für die Datenbank zur Verfügung steht.
Gründe:
* durch die weitere ODBC-Schicht verliert man an Performance
* die weitere Schicht bedeutet höhere Resourcenbelastung
* die ODBC-Schicht veringert den internen Funktionsumfang, da ADO mehr bietet als man
sich zur Zeit als ODBC entwickelt wurde vorstellen konnte.

[Macher]

Zitat von shmia:

Zitat von Macher:

Dadurch das ich über die ODBC, und nicht direkt auf die einzeln DBs zugreife bleibt der Provider immer gleich "MSDASQL.1" hmmm...

Es ist ein Fehler, den Umweg über ODBC zu nehmen, wenn ein OLE-DB Provider für die Datenbank zur Verfügung steht.
Gründe:
* durch die weitere ODBC-Schicht verliert man an Performance
* die weitere Schicht bedeutet höhere Resourcenbelastung
* die ODBC-Schicht veringert den internen Funktionsumfang, da ADO mehr bietet als man
sich zur Zeit als ODBC entwickelt wurde vorstellen konnte.

Stimmt schon, aber durch den "Umweg" bleibt das System offener. Ich kann schneller neue DB-Connections erstellen.

[shmia]

Zitat von Macher:

Stimmt schon, aber durch den "Umweg" bleibt das System offener. Ich kann schneller neue DB-Connections erstellen.

Nein, über UDL-Dateien bist du noch flexibler, als mit den System DSNs.
Du erzeugst dir einfach eine neue txt-Datei und benennst diese nach *.UDL um.
Mit dem Doppelklick darauf kannst du die Verbindung konfigurieren.
In deiner Anwendung setzt du dann den Connectionstring:

Delphi-Quellcode:

udlfilename := ChangefileExt(ParamStr(0), '.UDL');  // UDL heisst gleich wie deine Anwendung (nur ein Vorschlag)
ADOConnection1.Connectionstring := 'FILE NAME='+udlfilename;

[Macher]

Zitat von shmia:

Zitat von Macher:

Stimmt schon, aber durch den "Umweg" bleibt das System offener. Ich kann schneller neue DB-Connections erstellen.

Nein, über UDL-Dateien bist du noch flexibler, als mit den System DSNs.
Du erzeugst dir einfach eine neue txt-Datei und benennst diese nach *.UDL um.
Mit dem Doppelklick darauf kannst du die Verbindung konfigurieren.
In deiner Anwendung setzt du dann den Connectionstring:

Delphi-Quellcode:

udlfilename := ChangefileExt(ParamStr(0), '.UDL');  // UDL heisst gleich wie deine Anwendung (nur ein Vorschlag)
ADOConnection1.Connectionstring := 'FILE NAME='+udlfilename;

cool, die Sache hat nur einen Hacken... Es werden nicht alle DB unterstützt, bzw. es gibt die Treiber nicht dafür. Es fehlt z.B. Firebird/Interbase. Außerdem bleibt immer noch das Problem mit dem erkennen des Datenbanktypes...

[mikhal]

OLEDB Provider für Firebird:

ZStyleGroup: Shareware

IBProvider: gibt es auch als Freeware.

Grüße
Mikhal