![]() |
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Zitat:
Wahrscheinlich verleitet mich Delphi gerade zum Schlampen, denn genau das habe ich nicht mehr beibehalten. Connection und Query-Objekt auf Form/Frame werfen und das mit Grids, Charts und sonstwas direkt schön visualisieren. So habe ich locker schonmal zwei, drei Readonly-Verbindungen auf meine Datenbank. Verbindungen, die fest mit meiner Oberfläche verdrahtet sind. Die Anwendungslogik dahinter weiß von diesen Verbindungen nichts. Und will sie jetzt finden um sie auszuknipsen. Ziemlich blöd gelöst, oder? Irgendwie ging mir schon einer dabei ab, auf dem Formular-Designer schon den DB-Inhalt sehen zu können. Aber ich komme immer mehr zum Schluss, dass man es lieber "ordentlich" und alles über ein Verbindungsobjekt laufen lassen sollte... |
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Zitat:
|
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Fast! Ganz reichen meine Fähigkeiten leider nicht aus: Der Formular-Designer findet problemlos eine Verbindungs-Komponente die man auf ein ganz anderes Formular geworfen hat. Aber leider nur über die globale "Form2"-Variable.
Oder bezeichnet "Datenmodul" etwas, das ich nicht kenne? |
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
|
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Gut, dass ich nochmal nachgefragt habe :-)
Das sehe ich zum ersten mal. Und es sieht sehr, sehr vielversprechend aus. Zitat:
Eine Sache noch: Um das Verkoppeln von bsp. einem TDBGrid mit etwas von einem Datenmodul (oder anderen Formular oder Frame) komme ich aber anscheinend um diese blöde globale Variable nicht drum herum, oder? Papa sagt, globale Variablen seien böse. |
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Über irgend etwas musst du den Container ja referenzieren, und die globale Form-/DM-Variable ist ja schon von der IDE als "The correct Delphi way" vorgegeben. Ich habe mich aus praktischen Gründen damit abgefunden diese als letzte Vertreter ihrer Art zu tolerieren. (Ausser bei Formularen, die ich nur dynamisch instanziere.) Andere Lösungen (so es sie denn gibt) würden sehr wahrscheinlich auch nicht so einfach von der IDE unterstützt, so dass der Nutzen des Ganzen wieder fraglich wäre.
|
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Ich würde das hier auch rein pragmatisch sehen. Wenn du in der IDE die Live-Verbindung zur Datenbank willst, kommst du um diesen Weg wohl nicht herum. Denk auch daran, das Datenmodul in die automatische Form-Erzeugung mit aufzunehmen (außer: siehe unten).
Es ist auch nicht wirklich die globale Variable, die Delphi da verwendet, sondern vielmehr die Instanz dieses Datenmoduls mit dem entsprechenden Namen ("Wozu haben Komponenten Namen?"). Beim Laden der Forms löst Delphi die Referenz auf das Datenmodul auf, indem es die Namen der Instanzen überprüft. Das Verbindungsobjekt sucht es dann über FindComponent innerhalb dieser Instanz. Du kannst also problemlos zur Runtime selbst eine passende Instanz des Datenmoduls (vor den Forms) erstellen (den Namen bekommt es aus der DFM), das dann auch von den verschiedenen Forms verwendet wird. Die globale Variable kannst du dann auch entfernen. Es darf aber weiterhin nur eine Instanz dieses Datenmoduls geben - was aber ja auch der Sinn des ganzen ist. |
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Richtig, die Anwendung kompilierte zwar, konnte aber nicht starten, da in der
Delphi-Quellcode:
-Reihenfolge das Datenmodul nach dem Formular kam.
Application.CreateForms
Dann bedanke ich mich auf jeden Fall noch ganz anständig, denn insgesamt ist das, was ich die ganze Zeit wollte. 8-) |
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Zitat:
|
AW: Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz