DLL mit Delphi schreiben + Zugriff auf Daten

[cytrinox]

Hi,

kurz und bündig:
ich will eine DLL Datei mit Delphi schreiben, die auf Daten (Zeosquerys usw.) aus einem bestimmten laufenden Programm zugreifen kann.


Das ganze sollte so aussehen, dass das Programm eine eingebettete Datenbank öffnet (was es bereits schon tut). Jetzt habe ich ein zweites Programm, welches die DLL Datei einbinden soll. Über diese DLL Datei soll ein Zugriff auf die Datenbankverbindung des anderes Programmes hergestellt werden.

Was brauch ich alles dafür und... geht das überhaupt? :)

Also Shared Memory sollte ja z.b. kein Problem sein. wenn die DLL und die DBConnection in einem sharedmem Bereich liegen, sollte ja das gröbste an Problemen beseitigt sein. Locking usw. ist keine Schwierigkeit, da nur eines der beiden Programme aktiv sein kann.

Allerdings fehlt mir da in jeder Beziehung der entsprechende Ansatz :roll:

[Bernhard Geyer]

Willst du zwischen DLL und Exe Objekte austauschen müssen Exe und DLL mit Laufzeitpackages compiliert werden.
Ansonsten kracht es an allen Ecken und Enden mit diesen ausgetauschten Objekten.

[cytrinox]

Jau. Ich arbeite in dem Programm welches die DBConnection hält ja schon mit *.bpl Dateien. Diese werden allerdings aus dem Programm heraus geladen, somit kann ich auch problemlos die DBConnection an Funktionen der BPL übergeben.

Jetzt müsste ich aber eine DLL in ein Programm einbinden, das kein Verbindung hält, sondern über die DLL Datei auf die Verbdinung eines anderen Programmes zugreift.

[Bernhard Geyer]

Du meinst Du hast 2 Exes und die 2te Exe soll die Verbindung der ersten Verwenden?

[cytrinox]

genau so ist es.

dazu müsste die Connection usw. in einem shared memory bereich liegen worauf die DLL auch zugreifen kann (denk ich mal)

[Bernhard Geyer]

Zitat:

Zitat von cytrinox

dazu müsste die Connection usw. in einem shared memory bereich liegen worauf die DLL auch zugreifen kann (denk ich mal)

Nein! Vergiss es. Du kannst keine Delphi-Objekte über Anwendungsgrenzen transferieren. Da wirst Du das gleiche Problem haben wie ohne Runtime-Packages.

Lösungen wären:
- Eine Anwendung hat eine COM/Automatisierungsschnittstelle
- Für NamedPipes oder ähnliche Kommunikationsschnittistellen definierst du ein eigenes Protokoll um hier daten auszutauschen.

[cytrinox]

Wiso sollte es nicht möglich sein, einfach die Objekte der Connection in einen sharedmem Bereich zu legen?

Zur Not müsste es ja nichtmal die Verbindung selbst sein. Ich muss nur in Programm B irgendwie an die Daten rankommen die Programm A gerade in der Datenbank hat.

Mir würde es auch schon ausreichen wenn ich von B aus über die DLL auf bestimme Funktionen zugreifen kann die Programm A mir anbietet, also so dass ich gar kein Query absetze sondern einfach nur sage getTranslationForID(2342); und bekomme dann das Ergebnis (was in normalfall ein String ist und sich einfach über sharemem austauschen lässt.

[Bernhard Geyer]

Zitat:

Zitat von cytrinox

Wiso sollte es nicht möglich sein, einfach die Objekte der Connection in einen sharedmem Bereich zu legen?

Zur Not müsste es ja nichtmal die Verbindung selbst sein. Ich muss nur in Programm B irgendwie an die Daten rankommen die Programm A gerade in der Datenbank hat.

Mir würde es auch schon ausreichen wenn ich von B aus über die DLL auf bestimme Funktionen zugreifen kann die Programm A mir anbietet, also so dass ich gar kein Query absetze sondern einfach nur sage getTranslationForID(2342); und bekomme dann das Ergebnis (was in normalfall ein String ist und sich einfach über sharemem austauschen lässt.

Wenn du auf einfache "C-Kompatible-Elemente" gehst ist das was anderes. Das mag gehen. Aber lebende Objekte auszutauschen is nicht! Aber für den Austausch über Sharemem/Gemeinsamen Speicherbereich muss jemand anderes einspringen zum Helfen. Da habe ich keine Erfahrungen.

[cytrinox]

ok, mal ein anderer Ansatz, ich erklär auch mal warum ich das so machen will.

Über Programm A lade ich einen Crystal Report. der Report selbst bekommt seine DB Verbindung von Programm.
Die Feldnamen sind in einer zweiten Datenbank gespeichert, für deutsch, englisch usw.

Da man die Feldbezeichnung unter Crystal nicht aus einer Datenbank lesen kann, hab ich mir gedacht ich mach mir eine eigene User-DLL, die man in Crystal einbinden kann. Im Report benutz ich statt den Feldbezeichnung dann nur Formeln, die eine Funktion aus meiner DLL Datei aufruft, zusammen mit der Feld-ID.

Die DLL müsste jetzt nur noch _irgendwie_ die Daten aus der zweiten Datenbank bekommen, und da diese noch von eigentlichen Programm gelockt ist geht kein direkter Zugriff. Also ganz normale "C-Funktionen" würden dazu auch reichen.


Jetzt aber der neue Ansatz: Im Prinzip ruft das Programm ja nur die Crystal DLLs auf zur Anzeige des Reports. Diese DLL läd die User-DLLs nach, somit ist eigentlich alles im selben Adressraum.

Die Frage ist nur noch, wie ich jetzt aus meiner DLL auf Funktionen aus dem Hauptprogramm zugreife.

Kann ich mir einfach ein paar Funktionen bauen und in der DLL über irgend eine API die Funktionsadressen erfragen?