Fast Report - Leerzeile einfügen bei fehlendem Datensatz

[Jens Hartmann]

So nach längerem Nachdenken, Ja die "WHERE" Klausel schränkt das ganze ein. Allerdings funktioniert die "AND" Verknüpfung im JOIN auch nicht.

Das ganze mit der Hilfstabelle, ist eigentlich auch nicht der richtige Weg. Betrachte ich das ganze nämlich auf das Gesamtsystem, wäre die Umsetzung über eine Hilfstabelle wahrscheinlich nicht sinnvoll.

Es gibt System, die verfügen nicht nur über 256/512 Meldergruppen, sondern sind frei Konfigurierbar von z.B. 1 - 99999.

Somit wird das ganze wieder eine Formatierungsaufgabe.

Mein aktueller Lösungsansatz (So sollte es vermutlich funktioniere) sieht folgendermaßen aus:

1. Abrage der zugehörigen Meldergruppen zu der entsprechenden Anlagennummer:

SELECT * FROM MGV_EMA WHERE Anlagennummer = 1 2. Einen Record_Array oder eine Objekt erstellen und Query zuweisen

Delphi-Quellcode:

type
  T_MGV_EMA = record
    MG: string;
    Name: string;
  end;
...

var
  F_MGV_EMA : array of T_MGV_EMA

...

//Query dem Record über Schleife zuweisen

...

//Record prüfen und bearbeiten

...

//Record einem tfrxUserDataSet zuweisen

//Report erstellen

Jetzt stellt sich mir halt nur die Frage, kann es wirklich so aufwendig sein, eine einzelne däml... Leerzeile in eine Reporttabelle einzufügen, wenn die Spalte (1) nicht fortlaufend nummeriert ist.

Im Anhang mal ein Beispiel, von den aktuellen Dokumenten (Wir lösen das zur Zeit über Excel, jedoch manuell)

[Dejan Vu]

Wieso liest Du die Daten nicht einfach ein, kopierst sie in ein CDS, fügst Leerzeilen an den Stellen ein, die dir gefallen, und druckst das ganze vollkommen straightforward im FastReport aus? Das ist eine Sache von 5 Minuten und Du musst weder die Query noch deinen aktuellen Report anfassen...

[Sir Rufo]

Zitat von Dejan Vu:

Wieso liest Du die Daten nicht einfach ein, kopierst sie in ein CDS, fügst Leerzeilen an den Stellen ein, die dir gefallen, und druckst das ganze vollkommen straightforward im FastReport aus? Das ist eine Sache von 5 Minuten und Du musst weder die Query noch deinen aktuellen Report anfassen?

Bitte nicht, diese Vorgehensweise (PreProcessing in der Anwendung) hatte ich schon vorgeschlagen (vor allem weil mit Access gearbeitet wird)

[dataspider]

Ich habe mal schnell in Fastreport einen Report mit Lückenanzeige gemacht (siehe Anhang).
Ist auch relativ wenig Arbeit, man muss nur:

zum MasterData ein Child machen...
Die Daten ins Child...
Die Lückentexte auf MasterData
Und im MasterData PrinChildIfInvisible auf True setzen.

Code:

Var
  LetzteNummer: Integer;                                             
  AnzahlLuecken: Integer;                                             
    
procedure frxReport1OnStartReport(Sender: TfrxComponent);
begin
  LetzteNummer := 0;                                      
end;

procedure LabelLueckeOnBeforePrint(Sender: TfrxComponent);
begin
  LabelLuecke.Text := InttoStr(AnzahlLuecken) + ' fehlende Nummern';                                                       
end;

procedure MasterData1OnBeforePrint(Sender: TfrxComponent);
begin
  AnzahlLuecken := <frxDBDataset1."Nummer"> - 1 - LetzteNummer;
  LetzteNummer := <frxDBDataset1."Nummer">;                                          
  BandData.Visible := False;                                    
  if AnzahlLuecken > 0 then
    BandData.Visible := True;  
end;

begin

end.

Ich verlagere zwar auch gern alles auf die Datenebene, aber das hier kann man durchaus im Report lösen.

Frank

[Dejan Vu]

Zitat von Sir Rufo:

Bitte nicht, diese Vorgehensweise ..hatte ich schon vorgeschlagen...

Weil man Niemanden zu seinem Glück zwingen sollte? Die vorgehensweise von Dataspider ist mindestens genauso simpel, wenn man schon mal mit FR Scripten gearbeitet hat.

Na, ok. Ich halte mich raus.

[Sir Rufo]

Zitat von Dejan Vu:

Zitat von Sir Rufo:

Bitte nicht, diese Vorgehensweise ..hatte ich schon vorgeschlagen...

Weil man Niemanden zu seinem Glück zwingen sollte? Die vorgehensweise von Dataspider ist mindestens genauso simpel, wenn man schon mal mit FR Scripten gearbeitet hat.

Auch dazu hatte ich mich schon ausgelassen, und die Variante von dataspider würde ich immer dann wählen, wenn ich keinen Einfluss auf die Eingangsdaten habe, ich also nur den Report bearbeiten kann. Ansonsten wähle ich da PreProcessing (Daten vor dem Report aufbereiten) und das geschieht dann entweder in der Datenbank, oder wesentlich einfacher umzusetzen (und funktioniert dann immer, egal welche Datenbank) in der Anwendung.

Das PreProcessing kann ja auch relativ einfach implementiert werden mit einem Interface

Delphi-Quellcode:

IDataSetPreProcessor = interface
  function GetDataSet : TDataSet;
  procedure SetDataSet( Value : TDataSet );
  property DataSet : TDataSet read GetDataSet write SetDataSet;
end;

Dabei sieht die einfachste Umsetzung so aus

Delphi-Quellcode:

TNullDataSetPreProcessor = class( TInterfacedObject, IDataSetPreProcessor )
private
  FDataSet : TDataSet;
  function GetDataSet : TDataSet;
  procedure SetDataSet( Value : TDataSet );
end;

function TNullDataSetPreProcessor.GetDataSet : TDataSet;
begin
  Result := FDataSet;
end;

procedure TNullDataSetPreProcessor.SetDataSet( Value : TDataSet );
begin
  FDataSet := Value;
end;

Und ein spezielles würde dann aus dem Dataset vom Setter ein ClientDataSet erzeugen und diese Zeilen dazu mogeln und über den Getter das veränderte ClientDataSet liefern.

PS
Vor ein paar Tagen/Wochen hatte ich mich schon mal zum Thema Reporting ausgelassen und angeregt dem Reporter nicht direkt mit der Datenbank zu verbinden, sondern dem Reporter eine Struktur zu übergeben, aus der der Kontext (was sind das denn für Daten) und die Daten selber (z.B. als ClientDataSet-Binary/XML) zu übergeben. Der Reporter kann dann entscheiden, mit welchen Reports das dargestellt werden kann und auch (in diesem Fall) noch die Daten vorher bearbeiten (Leerzeilen einfügen).
Ein wesentlicher Vorteil ist das Speichern dieser Informationen um Berichte reproduzierbar speichern zu können und auch um dem Benutzer bei der Berichtsgestaltung eine Beispiel-Datenmenge an die Hand zu geben, die alle Möglichkeiten der Datenmenge beinhaltet.

[Dejan Vu]

Zitat von Sir Rufo:

Auch dazu hatte ich mich schon ausgelassen...

Das man niemanden zu seinem Glück zwingen soll?

Zitat:

Das PreProcessing kann ja auch relativ einfach implementiert werden mit einem Interface

Da tut es dann ein kleine Methode im Datenmodul doch auch. Nicht immer ist die Verwendung eines Interfaces oder einer supererweiterbaren Klasse sinnvoll (Stichwort: gas factory, accidential complexity). Aber das ist ein anderes Thema.

[Sir Rufo]

Zitat von Dejan Vu:

Zitat von Sir Rufo:

Auch dazu hatte ich mich schon ausgelassen...

Das man niemanden zu seinem Glück zwingen soll?

Zitat:

Das PreProcessing kann ja auch relativ einfach implementiert werden mit einem Interface

Da tut es dann ein kleine Methode im Datenmodul doch auch. Nicht immer ist die Verwendung eines Interfaces oder einer supererweiterbaren Klasse sinnvoll (Stichwort: gas factory, accidential complexity). Aber das ist ein anderes Thema.

Natürlich tut es das, aber irgendwie schreit hier doch einer immer bzgl. der Erweiterbarkeit herum :Morgen:
(s. mein Update vom vorherigen Beitrag)

[Jens Hartmann]

Zitat von dataspider:

Ich habe mal schnell in Fastreport einen Report mit Lückenanzeige gemacht (siehe Anhang).
Ist auch relativ wenig Arbeit, man muss nur:

zum MasterData ein Child machen...
Die Daten ins Child...
Die Lückentexte auf MasterData
Und im MasterData PrinChildIfInvisible auf True setzen.

markieren Code:
Var
LetzteNummer: Integer;
AnzahlLuecken: Integer;

procedure frxReport1OnStartReport(Sender: TfrxComponent);
begin
LetzteNummer := 0;
end;

procedure LabelLueckeOnBeforePrint(Sender: TfrxComponent);
begin
LabelLuecke.Text := InttoStr(AnzahlLuecken) + ' fehlende Nummern';
end;

procedure MasterData1OnBeforePrint(Sender: TfrxComponent);
begin
AnzahlLuecken := <frxDBDataset1."Nummer"> - 1 - LetzteNummer;
LetzteNummer := <frxDBDataset1."Nummer">;
BandData.Visible := False;
if AnzahlLuecken > 0 then
BandData.Visible := True;
end;

begin

end.
Ich verlagere zwar auch gern alles auf die Datenebene, aber das hier kann man durchaus im Report lösen.

Frank

Das funktioniert. Und ich denke, dem Aufwand gerecht. Keine Abhängigkeit von den Anzahl der Meldergruppen und optisch genau das was ich wollte.

Danke schon mal und Gruß Jens

[Sir Rufo]

Auf die Frage, ob es wirklich so schwer ist: Ja und Nein.

Da es noch keine Programmiersprache gibt die das DeveloperMindInterface unterstützt, muss man alles haargenau vorkauen.

Mit einer richtigen Datenbank erstellt man sich dafür eine StoredProcedure und gibt die Anlagennummer mit. Dann wird dort mit temporären Tabellen die gewünschte Struktur und Satzanzahl erstellt und zurückgeliefert. Das ist definitiv nicht schwer.

Darum als Antwort Ja und Nein