Reports allgemein Datentrennung

[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. :lol:

[Dejan Vu]

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

Frohes Fest. :lol:

[Hansa]

Zuerst einmal : frohe Weihnachten an alle.

Zitat:

Zitat von haentschman (Beitrag 1325014)

Genau...8-)
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?

[Hansa]

Beitrag wohl zu früh abgeschickt.

Ja, Fall 3 fehlt ja noch und das ist der wichtigste. Fest steht, dass die anzuzeigende/ zu druckende Datenmenge zuerst mal von Festplatte gelesen werden muss, egal wie.

Ich konstruiere mal ein Einsatz-Szenario : angenommen ich soll für einen neuen Mitarbeiter eine Preisliste von Art.-Nr. 1000 bis 2000 ausdrucken, die Datenmenge ist bereits da und wird auch schon in der Druckvorschau angezeigt. Nun fällt mir ein, dass eine von-bis Ausgabe nach Art.-Nr. eigentlich Blödsinnn ist, weil der Neue die Art.-Nummern noch kaum kennt. Alphabethisch wäre da wohl schon besser. Das hiesse dann : ORDER BY ändern, Datenmenge neu ermitteln und neu anzeigen usw.

Tja, Delphi hat schon mächtige Werkzeuge, die aber (leider) keiner benutzt. 99% können z.B. mit einem ClientDataSet (CDS) nichts anfangen, ausser mit dem Namen vielleicht. Darum gehts aber. Die Daten werden also wie gehabt eingelesen, landen aber dann nicht in irgendeinem DB-Zeugs, noch in vielleicht zu einfachen TLabel + Co., sondern eben direkt in einem CDS.

Wenn man das so macht, dann hat man quasi private Datenmenge. Man kommt keinem mehr in die Quere, ohne erneutes Lesen der Daten kann anders sortiert werden. Vor allem kann man aber auch datensensitive Sachen verwenden. Der Report kriegt dann nur das CDS als Datenquelle und fertig. Transaktionen, Deadlocks usw., alles uninteressant. Das läuft.

Die Vorzüge dieser Vorgehensweise muss man aber selber am Besten mal testen. Es gibt im Internet nämlich so gut wie nichts darüber zu finden. Ich kenne auch keinen, der CDS in der Praxis sinnvoll einsetzt. Doch, Stop ! Sakura macht das so ähnlich wie ich.

[Dejan Vu]

Zitat:

Zitat von Hansa (Beitrag 1325155)

Du weisst offensichtlich nicht, was datensensitive Komponenten sind ? Ich erkläre das dann eben mal : das DB vorne steht für Datenbank.

Zitat:

Zitat von Dejan Vu (Beitrag 1325165)

..Und ich dachte, DB steht für Dumpfbacke. Wieder was gelernt.:lol:

Zitat:

Zitat von Hansa (Beitrag 1325236)

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.

Na ja, Hansa. Bei der Frage und der Bemerkung solltest Du keine ernstgemeinte Antwort erwarten.

Zum Thema:
Ich glaube, es ging ursprünglich mal um Reports. Was das mit CDS und lokalen Variablen zu tun hat, weiß ich jetzt nicht. Auf den vorherigen Seiten wurden zwei Sichtweisen deutlich:
1. Der Report als Darstellungsknecht von Daten.
2. Der Report als autarkes Darstellungsmodul.

Wer Kontrolle über die Daten behalten will (oder muss), wählt eher Variante 1.
Wer Flexibilität benötigt bzw. wenn die Daten aus einer Datenbank geladen werden können, wählte eher Variante 2.

[mm1256]

Zitat:

Zitat von Dejan Vu (Beitrag 1325249)

Ich glaube, es ging ursprünglich mal um Reports. Was das mit CDS und lokalen Variablen zu tun hat, weiß ich jetzt nicht. Auf den vorherigen Seiten wurden zwei Sichtweisen deutlich:
1. Der Report als Darstellungsknecht von Daten.
2. Der Report als autarkes Darstellungsmodul.

Wer Kontrolle über die Daten behalten will (oder muss), wählt eher Variante 1.
Wer Flexibilität benötigt bzw. wenn die Daten aus einer Datenbank geladen werden können, wählte eher Variante 2.

Gut zusammengefasst. Man könnte noch ergänzen:
Wer Flexibilität und Kontrolle - flexibler Schwerpunkt je nach Aufgabenstellung - benötigt, der nimmt einen Report-Knecht der Beides kann, z.B. FR oder LL.

[Dejan Vu]

Ach so, klar. Ich bin davon ausgegangen, das man eine richtige Reportengine hat.