Firedac Tabelle mit dll teilen

[smarp]

Hallo zusammen, ich bin dabei, ein altes Projekt von der Bde auf Firedac umzustellen. Grundsätzlich geht es relativ einfach, nun bin ich allerdings an einem Punkt, wo ich etwas verzweifelt bin. Mit der Bde, TDatabase und TTable/TQuery-Komponenten hatte ich in meinem Hauptprogramm eine Verbindung zentral aufgebaut und alle nötigen TTable-Tabellen geöffnet. Nun konnten DLLs des Programms (mit Loadlibrary dynamisch erzeugt) sich an die Zentrale Stelle wenden (export-Methode) und z.B.ein TTable-Objekt holen, was einer bestimmten Tabelle entsprach. Unabhängig davon, ob das Design nun gut oder schlecht ist, es funktionierte ohne Probleme. Ich hatte dann in der DLL Zugriff auf die Tables des Hauptprogramms und konnte z.B. FindKey aufrufen, um an eine bestimmte Position in der DB zu springen.
Mit Firedac habe ich alles so gelassen, nur statt TDatabase TFDConnection genommen und entsprechend auch TFDTable usw. Der Code ist definitiv korrekt, ich kann mich verbinden und die Daten im Dbgrid Anzeigen lassen. Auch FindKey vom Hauptprogramm geht. Trotzdem bekomme ich bei FindKey aus der DLL, nachdem ich das TFDTable mir geholt hab, immer false zurück. Hat jemand zufällig Erfahrung darin? Kann es vielleicht sein, dass die Connection nicht richtig in der Dll ankommt, wenn ich mir das TFDTable-Objekt hole? Andererseits geht so etwas wie fdtable.fieldbyname(...) ohne Probleme aus der DLL. Daher verstehe ich nicht, warum FindKey nicht geht. Es ist auch das selbe TFDTable-Objekt, was ich von meiner exe zurückbekomme, Indexfieldnames ist auch korrekt, Tabelle und Connection sind geöffnet und alles. Trotzdem geht es nicht. Wäre dankbar für nen Hinweis, Zumal es ja mit TTable funktioniert. Ich hoffe, ich konnte das Problem einigermaßen erklären. FindKey war jetzt nur ein Beispiel, andere Dinge gehen glaub ich auch nicht richtig. Danke!

[Sinspin]

Wenn es vorher mit anderen Komponenten ging heißt das auch nicht dass es jetzt noch gehen muss. Es sind ja andere Komponenten!
Warum machst Du für die dll keine zweite Connection auf mit eigenen Tabellen? Das Teilen des Objektes zwischen Main und Dll halte ich für sehr gewagt.

[smarp]

Es sind verdammt viele Stellen, wo das Konzept so verwendet wird. Wie gesagt, es ist ein altes Projekt und schön wäre es natürlich, wenn es erstmal weiterhin so läuft und man nach und nach ein Refactoring macht.
Ich verstehe aber trotzdem nicht, warum es mit TTable geht und mit TFDTable nicht. Klar, es sind andere Objekte, aber letztlich sind es nur Objekte, die übertragen werden. Ich kann ja auch eine TStringList ohne Probleme zur DLL übertragen oder auch andere komplexere Objekte. Dass es nur an dem Typen liegt, glaube ich fast nicht. Es muss eher was mit der Connection zu tun haben, dass diese in der DLL vielleicht nicht erkannt wird?
Ich kann ja auch z.B. nicht ein TFDTable-Objekt in der DLL erzeugen und dort als ConnectionName den Namen der Connection aus dem Hauptprogramm nehmen. Oder weiß jemand, ob das irgendwie doch möglich ist?

[smarp]

Zudem ist das generelle Ziel, dass im Hauptprogramm die Zentrale Stelle für die Verbindung und den Tabellen ist und diese durch die DLLs auch angepasst werden können. z.B. durch FindIndex wird die Position in einer bestimmten Tabelle im Hauptprogramm verändert (aus der DLL oder aus dem Hauptprogramm heraus) und dadurch, dass alle DLLs diese Tabelle nutzen, werden die Daten überall entsprechend aktualisiert bzw. synchron gehalten. Was wäre ein besseres Konzept in FireDac für diese Anforderung?
Vielleicht noch als Info: Es wird überall ShareMem verwendet!

[peterbelow]

Zitat:

Zitat von smarp (Beitrag 1533476)

Zudem ist das generelle Ziel, dass im Hauptprogramm die Zentrale Stelle für die Verbindung und den Tabellen ist und diese durch die DLLs auch angepasst werden können. z.B. durch FindIndex wird die Position in einer bestimmten Tabelle im Hauptprogramm verändert (aus der DLL oder aus dem Hauptprogramm heraus) und dadurch, dass alle DLLs diese Tabelle nutzen, werden die Daten überall entsprechend aktualisiert bzw. synchron gehalten. Was wäre ein besseres Konzept in FireDac für diese Anforderung?
Vielleicht noch als Info: Es wird überall ShareMem verwendet!

Sharemem ist keine Lösung für dein Problem. Siehe meine Antwort in dem Thread, den Du in der englischen Delphi-Praxis aufgemacht hast.

[smarp]

Ja, vielen Dank Peter! Ich hab befürchtet, dass ich ein größeres Refactoring machen muss. Das sind verdammt viele Stellen, wo diese Aufrufe stattfinden. Dachte schon, ob man mit einer Singleton-Klasse das Problem lösen könnte, wo das Hauptprogramm und die DLLs drauf Zugriff haben, aber vermutlich wird das auch nicht funktionieren.
Der Wrapper scheint auch generell eine bessere und sauberere Lösung zu sein.

[Sinspin]

Wenn ein Objekt geht heißt das nicht das ein anderes auch geht. Selbst einer TStringList würde ich nicht unbedingt neue Einträge hinzufügen wollen und dann woanders wieder freigeben.
Das gleiche wird es mit dem Index sein. Die Connection habe ich eher weniger im Verdacht.
Die Tabelle wird intern für den Index Stukturen freigeben und neue anlegen. Da wird vermutlich etwas nicht so laufen wie es sein müsste damit es klappt.

[smarp]

Ich werde vermutlich eine BPL erstellen, die das Hauptprogramm und alle DLLs verwenden und dort die zentrale Stelle für den Datenbankzugriff anlegen. Man kann dann in den DLLs direkt auf die BPL und auf die dortigen Tabellen zugreifen.
In einem Testprojekt funktioniert das ohne Probleme.
Ein Wrapper wäre immer noch die bessere Lösung, wie ich finde, allerdings hätte ich damit enormen Refactoring-Aufwand, was momentan zeitlich einfach nicht machbar ist.
Danke nochmal für eure Hilfe!

[peterbelow]

Zitat:

Zitat von smarp (Beitrag 1533532)

Ich werde vermutlich eine BPL erstellen, die das Hauptprogramm und alle DLLs verwenden und dort die zentrale Stelle für den Datenbankzugriff anlegen. Man kann dann in den DLLs direkt auf die BPL und auf die dortigen Tabellen zugreifen.
In einem Testprojekt funktioniert das ohne Probleme.
Ein Wrapper wäre immer noch die bessere Lösung, wie ich finde, allerdings hätte ich damit enormen Refactoring-Aufwand, was momentan zeitlich einfach nicht machbar ist.
Danke nochmal für eure Hilfe!

Aber Achtung! Du mußt dann trotzdem alle RTL-und Firedac run-time packages mitliefern, sonst ist das Grundproblem weiterhin da.