Wieviele Verbindungen sind nötig

[Tobias Frost]

Konfiguriere ich eine TADOConnection für MS-SQL-Server gebe ich als Standard eine Datenbank vor (ansonsten würde ADO wohl die vom SERVER als Default gesetzte DB nutzen). In der weiteren Anwendung anderer ADO-Komponenten funktioniert diese Vorseinstellug auch sehr gut, solange ich mich auf Objecte aus der definierten Datenbank beziehe.

Ich kann über den CommandText aber auch auf andere DBs zugreifen ('SELECT * FROM DB2..TABLE') was mir das Öffnen einer weiteren Verbindung erspart, ich EINE Transaktion nutzen kann usw. Dieses Verfahren funktioniert aber nur, so lange ich die Einstellung 'cmdText' als CommandType angebe. Möchte ich z.b. eine Prozedure aus einer anderen Datenbank nutzen, kann ich das einer ADOStoredProc-Komponente nicht mitgeben, da sie immer die vom Connection-Object vorgegebene DB nutzt...

Was ist hier zu tun ? Ist es Standard, zu jeder DB eine separate Verbindung aufzubauen ? Oder ist es möglich, z.B. ein TBetterADODataSet vom Typ cmdText von Hand so zu konfigurieren, daß es eine Standard-DB-fremde Prozedur inklusive Parameter aufrufen kann ??

Tobias

[Andreas Kosch]

Hallo,

>Was ist hier zu tun ?

die Anwendung muss eine SP auf der eigenen Datenbank aufrufen - erst aus dieser SP heraus wird dann die SP der "fremden" Datenbank über die Syntax <i>Datenbankname.Eigentümer.SPName</i> aufgerufen. Wenn die fremde Datenbank jedoch auch auf einem separaten SQL-Server läuft, muss die erste SP auf OPENROWSET etc. zurückgreifen.

&gt;Ist es Standard, zu jeder DB eine separate Verbindung aufzubauen?

Selbstverständlich - denn etwas anderes würde ja gar keinen Sinn machen. ADO benötigt in jedem Fall die Zugriffsinformationen (Datenbankname, Benutzername, Passwort, etc.) sowie eine aktive Datenbank-Session - denn die Regeln stellt nicht ADO auf, sondern die verwendete Datenbank

[Tobias Frost]

Danke der Resonanz !

Aber: Das Connection-Object stellt doch die Verbindung zu EINEM Server her. Sämtliche bei diesem Server registrierten Datenbanken sind dann doch im Zugriff durch meine Anwendung. Ich kann ja auch mittels eines ADODataSets Joins über mehrere Datenbanken machen, sofern diese eben bei dem EINEN Server registriert sind. Warum also weitere Anbindungen, wenn sich doch alles mit einer erledigen läßt ? Und wie funktioniert das denn mit Datenbankübergreifenden Transaktionen wenn ich mehr als eine Verbindung habe ?

Tobia

[Andreas Kosch]

Hallo,

&gt;..Aber: Das Connection-Object stellt doch die Verbindung zu EINEM Server her...

diese Beschreibung ist zu grob - exakter wäre die folgende Formulierung: Das Connection-Objekt stellt die Verbindung zu einer <b>Datenbank-Sitzung</b> im Kontext einer Transaktion für diesen Benutzer her. Der SQL-Server muss die verschiedenen Sitzungen so voneinander abschirmen, als ob der Benutzer der einzige wäre, der mit dieser Datenbank arbeitet. Es können niemals mehrere <b>aktive</b> Datenbank-Sitzungen über die gleiche Leitung (Connection) verwaltet werden. Aus diesem Grund spaltet das Connection-Objekt auch implizit (d.h. für uns unsichtbar) immer dann zusätzliche Verbindungen ab, wenn die Leitung noch durch die letzte Aktion belegt ist, aber das Programm eine neue Aktion ausführt.

&gt;..Datenbankübergreifenden Transaktionen ...

dafür gibt es zwei Standard-Implementierungen: <br>
1. Implizites 2-Phasen-COMMIT der deklarativen Transaktionen von COM+ bzw. .NET Enterprise Services <br>
2. Explizite Transaktionssteurung über beide Verbindungen durch das eigene Programm (TADODataSet-Methoden CommitTrans und RollbackTrans)