Data module / Umstieg von ttable auf fdquery

[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 von 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?

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

[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