Data module / Umstieg von ttable auf fdquery

[MES]

Hallo miteinander, habe ein Verständnisproblem im Einsatz der Datamodule bzw. der Datasets in den DM.
Ich habe etwa 150 fdquery mit dazugehörenden Datasource. Diese habe ich in 5 Datamodule alphabetisch untergebracht.
Nun nehme ich ein Formular A das auf eine fdQuery aus dem DM referenziert und setze im DM die entsprechende SQL Anweisung (Select *...)
Wenn ich nun aus einem Formular B die gleiche fdQuery mit einer anderen SQL Anweisung brauche dann überschreibe ich
ja die Anweisung die für das Formular A benötigt wurde - oder denke ich da falsch?

Mein Problem also: Wie greife ich mehrfach und unter verschiedenen Bedingungen auf das gleiche Dateset (fdQuery), das sich einmalig im DM befindet, zu ohne das mir die formularbezogene SQL Anweisungen gegenseitig stören? Ich hoffe, dass ich nicht alle Datasetz auf das jeweilige Formular platziern muss.
Unter BDE und ttable war das kein Problem weil es keine gespeicherte SQL Anweisung im DM gab (table.open, index setzen...).

Ich hoffe auf ein paar Tipps die mich weiterbringen. Vielen Dank.

[mkinzler]

Bei der Verwendung von datensensitiven Komponenten wird das nicht funktionieren. Du benötigst dann pro Formular eine Aktive Abfrage.

Zitat:

Diese habe ich in 5 Datamodule alphabetisch untergebracht.

Warum das? Ich würde diese eher funktional gruppieren. Wenn neue eingefügt werden müsste man dann ja auch umsortieren, was ernorme Änderungen in den Formularen zur Folge hätte.

Wenn Du die SQL-Anweisungen eh überschreibst, wäre in Deinem Fall dann lokale Komponenten sinnvoller.

Ich würde aber Dein gesamten Konzept überdenken.

[MES]

Teilweise sind die Namen der Funktion zugeordnet (Angebot/Auftrag..). Diese sind in einem DM.
Es gibt aber auch welche die verschiedenste Funktionen haben, so z.B. der Artikelstamm. Neben Artikelinfos führt er auch den Bestand. Das könnte ich nun unter "Lager" oder "Artikelstamm" führen. Aber das ist nicht mein Problem.

Ich verstehe nicht warum man Datamodule hat wenn ich die Inhalte(Datasource und/oder Dataset) dann doch aufs Formular ziehen muss. Es muss doch eine Möglichkeit geben
das Dataset "zu kapseln" oder sowas. Da ich ein SQL Anfänger bin tu ich mir noch schwer alles 100%ig zu verstehen.

Ich bin gerne bereit alles zu überdenken(bin noch heftig BDE/tTable infiziert) und freue mich auf Anregungen.

[mkinzler]

Eine DataSource ist nur ein Bindeglied zwischen dem DataSet und den datensensitiven Komponenten.

[MES]

Soweit bin ich schon :-D.
Aber wie spreche ich das Dataset aus der DM an ohne das sich die unterschiedlichen Selects aus den unterschiedlichen(offenen) Formulare gegenseitig stören?

[mkinzler]

Gar nicht. Es wird mit dem DataSet verbunden und angezeigt. Wird dessen Inhalt verändert, ändert sich auch der Inhalt in den Anzeigekomponenten!

Wenn Du 150 Freunde einlädst benötigst Du auch 150 Gläser!

[p80286]

aber es reicht eine Bardame (query) die die Gläser füllt.
deine Freunde (componenten?) müssen sich nur selbst um ihre Gläser (Daten) kümmern.


Gruß
K-H

[MES]

OK, Du meinst also auf das jeweilige Formular die fdquery und die DS setzen.
Ich hab bissl rumgesucht und festgestellt, dass ich über Fieldoptions das Verhalten der Query beeinflussen kann.
So kann ich ein namensgleiches Dataset auf das Formular platzieren(und auf dem DM) und über die Feldoptions bestimmen das
die Tabelenfelder+die formularbezogenen Felder (z.B. Lokup, berechnete Felder) automatisch eingelesen werden (Combined).
Das ist eine große Hilfe denn somit muss ich nicht bei jeder Tabellenerweiterung daran denken die einzelnen Formulare bzw. die Datasets die drauf sind
ändern zu müssen.

Hast es so gemeint?

[jobo]

Zitat:

Zitat von MES (Beitrag 1342640)

Ich habe etwa 150 fdquery mit dazugehörenden Datasource. Diese habe ich in 5 Datamodule alphabetisch untergebracht.
Nun nehme ich ein Formular A das auf eine fdQuery aus dem DM referenziert und setze im DM die entsprechende SQL Anweisung (Select *...)
Wenn ich nun aus einem Formular B die gleiche fdQuery mit einer anderen SQL Anweisung brauche dann überschreibe ich
ja die Anweisung die für das Formular A benötigt wurde - oder denke ich da falsch?

Auf die Gefahr hin, dass ich das Problem selbst nicht verstanden hab:

Wenn schon 150 verschiendene(!?) fdquery da sind, was sprich gegen die 151. Query, die genau passend ist. Statt eine "fremde" Query zu "misbrauchen"?

Andersrum/ anderes Konzept:
Wenn schon Queries dynamisch befüllt werden- was ja scheinbar irgendwie der Fall ist-, warum dann noch 150 Stück davon? Wieso nicht je Bedarf ein QueryObjekt erzeugen (dann muss ich nur irgendwo die Tablenames oder Abfrage Statements verwalten.

[MES]

Ja... ok... aber irgendwo musste ich seither die jeweiligen Tables dem Projekt mitteilen.

[jobo]

Das ist ja ok, ich frage mich nur, warum jetzt ausgerechnet Form B die Query von Form A braucht bzw. sogar überschreiben muss. Warum hat Form B keine eigene Query?

[p80286]

Wahrscheinlich ticke ich anders, aber mehr als 3 Queries habe ich noch nie gebraucht.
Da jeder Abfragetext in sich auch die Definition der Ausgabe trägt, benötigst Du meist nur eine Query, die Du mit den verschiedenen Texten fütterst. Die Ausgabewerte kannst Du dann abhängig von der Eingabe wieder abholen, in meinem Fall sind das überwiegend Stringlisten, aber das kommt auf die Daten an. Ob diese dann in einem Grid/Listview... angezeigt werden oder anderweitig verarbeitet werden interessiert zuerst einmal nicht.
Du kannst es auch von der anderen Seite sehen, Deine Anwendung benötigt Daten, die von einem Datenmodul geliefert werden. Ob hierin eine Query werkelt oder ob eine Datei gelesen wird interessiert Deine Anwendung auch nicht, die will nur Daten.

Gruß
K-H

[hoika]

Hallo,
kann es sein, dass du mit persistenten Feldern arbeitest,
z.B. jedes Feld der Query noch irgendwie per Doppelklick bearbeitest (DisplayMode, oder wie das heisst?
Dann brauchst du wirklich für jeden Fall eine eigene Query.

Ich habe nicht 3, sondern 1 Query für die Anwendung.
Das SQL-Statement wird immer dynamisch zusammengebaut.
Da ich kaum Threads benutze, teilen sich alle Formulare diese eine Query das DataModuls.

PS:
BDE, Paradox, TTable: Das waren noch Zeiten ... ;)

Heiko

[MES]

Zitat:

Zitat von jobo (Beitrag 1342666)

Das ist ja ok, ich frage mich nur, warum jetzt ausgerechnet Form B die Query von Form A braucht bzw. sogar überschreiben muss. Warum hat Form B keine eigene Query?

In dem Datamodul(DM) hab ich z.B. den Artikelstamm als Query
In der Form A hab ich ein Grid mit dem Artikelstamm der z.B. eine Selektierung hat auf alle Artikel die einen unterschrittenen Mindestbestand haben. Auf diesem Formular(A) hab ich keine Query sondern nutze die Artikemstammquery aus dem DM.
Auf der Form B hab ich den Artikelstamm der z.B. selektiert welche Artikel die Farbe rot haben.
Dazu nutze ich auch die Artikelstammquery vom DM - diese ist aber für die Form A selektiert und wenn ich nun einen anderen "Select * from Artikelstmm..." als SQL Anweisung setze überschreibe ich den SQL-Text von Form A. Der User kann aber beide Formulare offen haben. Nun könnte ich sagen "on activate neu einlesen" aber das wollte ich nicht.

[Sir Rufo]

Ich würde die Queries nicht alphabetisch in den DMs organisieren, sondern nach Aspekt.

Die Statements selber würde ich auch fest eintragen und mit den Parametern die Kriterien festlegen.

Wird jetzt für ein Formular so ein Aspekt benötigt, dann erzeuge ich mir eine Instanz des DM.

Schon kommt sich keiner mehr in die Quere :stupid:

[Frickler]

Wenn Form A und Form B feste Funktionalitäten haben, macht Du einfach eine QueryA für Form A und eine QueryB für Form B. Aber wenn Form A und Form B einfach nur zwei Instanzen der gleichen Formklasse sind, nur halt mit unterschiedlichen Parametern erzeugt, dann bietet sich ne Factory an, der man die Art des Formulars ("Artikel in roter Farbe") und die zugehörige SQL-Anweisung übergibt und die dann das passende Formular samt Datenmodul mit der Query drauf (oder einem Clientdataset) fertig verdrahtet instanziiert.

[Sir Rufo]

Das 1. Konzept ist natürlich bei n Formularen etwas sehr sperrig und grundsätzlich sehr unübersichtlich.
Das 2. Konzept ist auch nicht gerade komfortabel.

Eine Trennung in Form (Darstellung) und DataModul (Daten zum Darstellen) bietet sich aus vielen Gründen an und das Konzept funktioniert für 1-n DataSets im DataModul. Die Form ist nicht zu überfrachtet und kümmert sich nur um die Darstellung.

[ConnorMcLeod]

Habe ich das richtig verstanden, daß die Queries und Datasources sozusagen doppelt vorhanden sind?
Einmal im Datenmodul, einmal in den Forms, die die datensensitiven Kompos beherbergen?
Wenn ja, dann ist das unnötig, weil die Datasources des Datenmoduls verwendet werden können.
Im Quelltext der Form im uses des interface Teils wird der Dateiname des Datenmoduls eingetragen.
Dadurch schlägt Delphi die Datasources im ObjectInspector schon vor...
HTH

[mkinzler]

Nein, er möchte die vorhandenen Datenzugriffskomponenten auf einem Datenmodul wiederverwenden ohne den Inhalt vorhandener "Verwendungen" ( aus anderen Formualren) zu ändern.

[ConnorMcLeod]

Ah, ok. Ich würde auch gerne meine Geldzugriffskomponenten (Bankkarten) wiederverwenden, ohne den Betrag vorhergehender Kontostände zu verändern ;-)