Reports allgemein Datentrennung

[Devil1925]

Gebe ich also auch mal meinen Senf dazu:

Bei uns wird ein System mit Reportstartern verwendet, bei welchem jederzeit neue Reports eingebunden werden können. Dadurch ist es schlichtweg nicht möglich für Alle Reports eine Datenquelle bereitzustellen, da über diesen einen Reportstarter X-Beliebig viele Reports gestartet werden können, welche sich auf X-Belibieg viele Datenquellen beziehen.

[Hansa]

Zitat von Devil1925:

... bei welchem jederzeit neue Reports eingebunden werden können. Dadurch ist es schlichtweg nicht möglich für Alle Reports eine Datenquelle bereitzustellen, da über diesen einen Reportstarter X-Beliebig viele Reports gestartet werden können, welche sich auf X-Belibieg viele Datenquellen beziehen.

Sehr merkwürdig. Das soll verstehen wer will. Wie ich das Thema hier aber sehe, dann geht die Frage sowieso eher um den Einsatz datensensitiver Komponenten (Reports zähle ich da im Zusammenhang auch dazu). Tatsache ist nun, dass die logisch zwar sinnvoll wären, es kriegt aber keiner so richtig hin (egal ob Delphi oder Komponenten-Entwickler). Auch bei den (neueren) Data-Bindings scheint sich das fortzusetzen, es ist nicht wirklich richtig brauchbar. Die Programmierung dieses Krempels ist anscheinend komplizierter als gedacht. Konsequenz ist dann eben : besser nicht benutzen. Ist ja eigentlich auch nicht wichtig. Per FieldbyName etc. kann ich auch alles aus einem Dataset auslesen. Da braucht man kein DBGrid. Kaum zu glauben, aber es gibt noch eine Welt neben dem zusammenklicken und das nennt sich "programmieren".

Jetzt wieder zu den Reports : wenn jemand den Report die Datenmenge ermitteln und auch ausdrucken lässt, dann kann der das eben so machen. Er kann auch Komfort, wie Druckvorschau weglassen. Kann man noch was weglassen ?

[Dejan Vu]

Bei Fastreport ist doch ein Previewer / Durckvorschau dabei? Der FR-Engine ist das doch vollkommen egal, wer die Daten bereitstell: Entweder über die Anwendung oder den in der FR-Datei selbst definierten Datenquellen... Was hat das alles nur mit nem Grid zu tun?

[Hansa]

Du weisst offensichtlich nicht, was datensensitive Komponenten sind ? Ich habe ein DBGrid angeführt und kein "Grid". Ich erkläre das dann eben mal : das DB vorne steht für Datenbank. Und es gibt da auch noch DBEdit, DBText usw. Der Unterschied zu einem "normalen" TEdit, der besteht z.B. darin, dass man eine Datenquelle angeben muss, die diese Komponenten befüllt. Dafür gibt es in Delphi die Komponente TDatasource. Rest ist mir jetzt zu blöd.

[Dejan Vu]

Mann, Datenbank? Und ich dachte, DB steht für Dumpfbacke. Wieder was gelernt.

Frohes Fest.

[Hansa]

Zuerst einmal : frohe Weihnachten an alle.

Zitat von haentschman:

Genau...
Jetzt kann sich jeder, anhand der Argumente, aussuchen wie es am optimalsten zu seiner Anwendung paßt.

Aber trotz Friede, Freude, Eierkuchen muss ich da widersprechen. Hier sind leider kaum stichhaltige Argumente zu finden für oder gegen was eigentlich ?

Meine Anmerkung mit dem DBGrid wurde offensichtlich nicht verstanden (zumindest von Dejan Vu) und da kam nur "Dumpfbacke" dabei raus. Ansonsten kam aber auch nichts Neues.

Prinzipiell gibt es doch nur 3 Fälle, wie man vorgehen kann. In allen drei Fällen muss normalerweise die auszudruckende Datenmenge bestimmt werden. Also "select x,y... from blabla". Nun habe ich in meinem Dataset/Query irgendwelche Daten drin. Die drei Möglichkeiten, wie es dann weitergeht, die unterscheiden sich aber dann doch erheblich :

Fall 1 : schätze 80 % benutzen DB-sensitive Komponenten. Schnell hat man da ein sichtbares Ergebnis. Allerdings : die Flexibilität leidet stark. Im unvermeidlichen Fehlerfall ist die Suche nach der Fehlerquelle schon sehr aufwändig.

Fall 2 : Man schaufelt die Datenbank-Daten in lokale Variablen, TLabel usw. Das hätte zumindest zur Folge, dass keine Datenbankfehler mehr auftauchen können.

[TBx]

Und Fall 3?