ADOConnection von einem Anderen Programm verwenden???

[Markus Jung]

Hallo!

Ich hätte ein kleines Problem und würde mich freuen, wenn mir jemand sagen könnte, ob folgendes möglich ist:

Ich würde gerne eine Datenbank-Anwendung schreiben, die aus 2 Teilen besteht. Einem "Connection-Server" und dem Hauptprogramm wobei der "Connection-Server" und das Hauptprogramm zwei verschiedene Programme sind. Dies soll dann so funktionieren, dass in dem "Connection-Server" die ADOConnection zur Datenbank in einem geöffneten Zustand vorgehalten wird, so dass ich aus meinem Hauptprogramm bei einem z.B. ADODataSet diese Verwenden kann.
Ich würde also gerne aus einem Programm die ADOConnection von einem anderen nutzen? Ich habe gehört das es in VB möglich ist. Ist es denn auch in Delphi möglich und wenn ja, wie????

Es wäre wirklich sehr nett wenn mir jemand helfen könnte.

Vielen Dank,

Markus Jung

[Andreas Kosch]

Hallo,

im richtigen Leben ist vieles vom dem, was möglich ist, nicht sinnvoll. Hinter dem Connection-Objekt verbirgt sich ein normales COM-Objekt, und über den Marshaler kann ein Interface-Zeiger auf eine COM-Objektinstanz über Prozess- und Rechnergrenzen hinweg transportiert werden. Somit kann eine Anwendung A rein technisch gesehen auf eine Objektinstanz der Anwendung B direkt zugreifen. Im Fall im ADO schiesst man sich dabei jedoch selbst ins Bein - und zwar mit einer ganz grossen Flinte :-)

Hinter ADO steckt als Unterbau <b>OLE DB</b> und damit steht auch der automatische Datenbankverbindung-Pool von OLE DB zur Verfügung, der je Anwendung gilt. Der Versuch, einen Interface-Zeiger auf eine "fremde" Connection-Objektinstanz in den eigenen Prozess (Apartment) zu retten, führt zu einem sehr trägen und unhandlichen Gebilde.

Wenn mehrere EXE-Anwendungen über die gleichen Datenbankverbindungen arbeiten sollen, ohne dass es dabei zu Problemen kommt, ist der folgende Weg üblich:

1. Alle Datenbankfunktionen werden in Form von COM+ Objekten in eine COM+ Anwendung (Host-Prozess) installiert. Somit liegen alle Objektinstanzen im Gültigkeitsbereich des gleichen Datenbankverbindungs-Pools von OLE DB.

2. Alle Anwendungen rufen immer dann die COM+ Objekte in der COM+ Anwendung auf, wenn eine Datenbankaktion stattfinden soll. Anstelle die Verbindung zu übergeben, fordern die EXE-Anwendungen nur das <b>Ergebnis</b> (Recordset-Objektinstanz im <b>ltBatchOptimistic</b>-Modus) ab. In der EXE-Anwendung gibt es keine TADOConnection-Komponente, sondern nur TADODataSet - wobei die Anwendungs-EXE keinen direkten Zugang zur Datenbank hat. Im Sprachgebrauch von Borland ist der ltBatchOptimistic-Modus auch als "Briefcase"-Modus von MIDAS bekannt. Sowohl MIDAS als auch ADO können mit "getrennten" Datenmengen umgehen, die auch dann editierbar sind, wenn es gar keine direkte Datenbankverbindung gibt.

3. Hat die Anwendungs-EXE (oder der Benutzer) die Daten der ltBatchOptimistic-Recordsetinstanz geändert (neue Datensätze hinzugefügt, geändert oder gelöscht), so übergibt die EXE das Recordset-Objekt wieder an die COM+ Anwendung. Dort wird die Recordset-Objektinstanz mit einer gerade freien Datenbankverbindung aus dem Pool verbunden (TADOConnection), so dass die ADO-Methode <b>UpdateBatch</b> alle Änderungen in der Datenbank einarbeitet.

4. Da jede EXE-Anwendung das COM+ Objekt nur für Bruchteile eine Sekunde benötigt, reichen sehr wenige Datenbankverbindungen im OLE DB-Pool aus (unabhängig davon, wieviele EXE-Anwendungen auf diese Objekte zugreifen).

P.S: Mit dieser Architektur wäre die eigene Delphi-Anwendung sogar topaktuell, denn unter .NET (ADO.NET) steht nur dieses Prinzip zur Verfügung (auch wenn dort alles in einer Anwendung verpackt werden kann und das Auslagern in eine COM+ Anwendung nicht unbedingt notwendig ist).
&#10

[Markus Jung]

Hallo Herr Kosch!

Vielen Dank schon mal für die super Tips. Der MTS bzw. Die Component Services scheinen ja in Zukunft eine grosse Rolle zu spielen.

Nun, da mögen Sie wohl recht haben, dass dieser Versuch zu Performane-Einbußen führt. Lassen Sie mich aber kurz erklären warum ich so etwas vor habe.

Mir geht es darum, für eine Produktpalette eine einheitliche Verbindungskomponente zu haben. Diese Verbindungskomponente soll nicht nur dazu dienen, das Connection-Objekt vor zu halten sondern sie soll auch das Eingangsportal für den User sein. An dieser Komponente soll er sich anmelden müssen, um die anderen Programme zu starten, so dass diese keine eigene Anmeldelogik mehr haben. Dies um eine Art Single-Sign-On zu erwirker.

Je länger ich doch darüber nachdenke, so schwachsinniger erscheint mir das Ganze.

- Macht das Sinn??
- Können Sie mir bitte helfen, wie ich eine schöne Anmeldelogik hin zu bekommen??

Vielen Danke und viele Grüße,

Markus Jun

[Andreas Kosch]

Hallo,

&gt; ...wie ich eine schöne Anmeldelogik hin zu bekommen...

ich würde in diesem Fall den "Connection-Server" nur dazu verwenden, um nach dem korrekten Login die Verbindungszeichenfolge (inklusive Benutzername/Passwort) für die Datenbank an alle anderen Clients (EXE) zurückzuliefern. Somit kann der Benutzer erst nach dem Login beim "Connection-Server" auf die Datenbank zugreifen, ohne die ADO-Connections prozessübergreifend nutzen zu müssen

[Markus Jung]

Hallo Herr Kosch!

Vielen Dank!
So etwas in der Art hab ich mir auch schon gedacht.
Denken Sie, so etwas macht Sinn??
Gibt es denn Literatur, Anwendungsbeispiele oder ähnliches, wie man eine schöne Anmeldelogik abbilden kann???

Wenn ich diesen Weg nun gehen möchte, wie kann ich von meiner Hauptanwendung bei dem "Connection-Server" prüfen, ob der Benutzer angemeldet ist??
Da muss ich ja auf z.B. Variablen oder Funktionen zugreifen, oder??
Ist das möglich??

Vielen Dank und viele Grüße,

Markus Jun