Summenberechnung mit Fastreport

[FediDelPr]

Hallo zusammen

Ich habe seit neuem ein Problem bei dem ich nicht weiterkomme:

Es geht um die Summenbildung, die bis jetzt gut funktionierte,
jetzt aber in einem von mehreren Reports in derselben Anwendung nicht mehr.

Ich verwende FastReport V6.0, seit gestern Abend V6.5 und Delphi Berlin 10.1.

Ich möchte eine einfache Summenbildung realisieren.
Das Grundsystem besteht aus den Bändern: Header/MasterData/Footer. Im Footer wird die
Summenbildung platziert. Die Grösse die aufsummiert werden soll ist im Band MasterData
vorhanden (wird auch richtig angezeigt).

Das eigenartige ist, dass als Summe folgendes erscheint:
Angenommen die aufzusummierenden 3 ersten Einträge seien:

177.30
232.10
29.75

erscheint als Summe 177.3232.129.75
Das Resultat wird aus den Zeilenwerten verschoben zusammengesetzt.

Kennt jemand diesen Effekt ?

Ich versuchte den Report abzuspecken bis auf die notwendige Einträge.
Ebenso bildete ich einen neuen Report. Auch hier zeigte sich dasselbe verhalten.

Auch habe ich den Fastreport neu geladen (neueste mir zugängliche Version 6.5.7),
das Problem ist nicht weg.

Bei weiteren (älteren) Reports die diese Summation verwenden funktioniert
die Summation wie erwartet.

Danke für eure Hilfe.

[jobo]

Sieht so aus, als ob hier eine NICHT-ZAHL konkateniert wird, statt zu summieren.
Der Punkt ist ja offenbar der Dezimal Trenner, was m.E. schon auf irgendeine falsche Einstellung oder gleich Zahlen in Textform hindeutet.

[Klaus01]

wenn die Zahlen als text zusammengesetzt worden wären,
sollte das "Ergebnis" dann nicht 177.30232.1029.75 lauten?

Grüße
Klaus

[Lemmy]

Zitat:

Zitat von Klaus01 (Beitrag 1454844)

wenn die Zahlen als text zusammengesetzt worden wären,
sollte das "Ergebnis" dann nicht 177.30232.1029.75 lauten?

nicht zwingend.. wenn der Wert 177.3 ist und die 0 nur wegen Formatsetting dazu kommt wäre das schon ne Lösung. Nur ist mir nicht klar, wie so was mit der eingebauten Summenfunktion erreicht werden kann.

[FediDelPr]

Ich werde den Einfluss des Formats mal genauer ansehen. Allerdings
denke ich ist das Format in den funktionierenden Beispielen das selbe.

[FediDelPr]

Das Format ( %2.2n ) hat keinen Einfluss auf das Berechnungsresultat.

Aber ich habe ein weiteres Problem festgestellt: MAX und MIN liefern nicht die
richtigen Resultate. Der Wert kommt zwar vor, er ist aber weder der grösste noch
der kleinste. Wenn ich dasselbe in einem weiter vorhandenen Bericht derselben
Anwendung ausführe funktionieren die Funktionen (SUM,MAX,MIN).

Ich versuche jetzt mal den funktionierenden Bericht als Basis zu verwenden und diesen
laufend in den gewünschten überzuführen.

[jobo]

Das Format ist in dem Moment uninteressant, wenn es auf einen Wert trifft, der bereits von Anfang an ein String ist. Das ist zumindest das, was ich vermute.

[Lemmy]

Zitat:

Zitat von FediDelPr (Beitrag 1454913)

Ich versuche jetzt mal den funktionierenden Bericht als Basis zu verwenden und diesen
laufend in den gewünschten überzuführen.

wie kommen die Daten denn in dem Report? frxUserDataset oder frxDBDataset? Wenn DB Dataset, sind das "Normale" Datentypen oder evtl. Ergebnisse von SQL-Funktionen (Select SUM(x) from...)? Wenn das Ergebnisse von SQL-Funktionen sind, kannst Du bei dem DBMS ein CAST zu einem Float machen?

[FediDelPr]

Die Daten kommen von einem frxDBDataset.

Ich bin noch nicht sicher, aber einiges deutet darauf hin, dass es bei Verwendung von
UNION (in ADOQuery) nicht richtig funktioniert.

Das eigenartige Resultat (wie CONCAT) deutet tatsächlich darauf hin, dass Strings verarbeitet
werden und nicht DOUBLE/FLOAT.

Hier ein Auszug aus dem SQL-Text:

kommt noch, es gibt da ein Problem beim Einfügen des SQL-Textes

[FediDelPr]

Hier der SQL-Text:

Code:

SELECT
  :ParamInt1 AS Konto,
  Datum,
  Beleg,
  Buchungstext,
  KontoS AS Gegen,
  Betrag AS BetragS,
  '' AS BetragH,
  Kontobezeichnung
FROM
  Buchungen bu
LEFT JOIN Kontenplan kp
ON bu.KontoH = kp.Kontonr

WHERE (KontoH = :ParamInt2) AND
      Datum BETWEEN :ParamDate1 AND :ParamDate2

UNION

SELECT
  :ParamInt3,
  Datum,
  Beleg,
  Buchungstext,
  KontoH AS Gegen,
  '' AS BetragS,
  Betrag AS BetragH,
  Kontobezeichnung
FROM
  Buchungen bu
LEFT JOIN Kontenplan kp
ON bu.KontoS = kp.Kontonr

WHERE (KontoS = :ParamInt4) AND
      Datum BETWEEN :ParamDate3 AND :ParamDate4

[FediDelPr]

Hab jetzt mal '' durch 0 ersetzt, die Berechnung scheint jetzt zu funktionieren.
Also war doch der Typ STRING im Spiel.

Was mir aber nicht passt:

Sobald der Betrag in der DB = Null ist soll nicht 0.0 sondern nichts ('') dargestellt werden.
Ich vermute da ist eine Nachbearbeitung (z. B. OnAfterData) notwendig.

[Luckie]

Warum spielt das eine Rolle, was intern in der Datenbank steht? Sieht doch eh niemand.

[FediDelPr]

Nicht in der DB, sondern im Ausdruck.

[jobo]

Also wenn Du die Strings selbst reinmischt, kommen halt auch Strings raus, oder?

1. da gehört dann wohl in den Ausdruck NULL hin, statt 0 oder ''
2. das union ist vermutlich auch überflüssig

[p80286]

Zitat:

Zitat von jobo (Beitrag 1455023)

Also wenn Du die Strings selbst reinmischt, kommen halt auch Strings raus, oder?

1. da gehört dann wohl in den Ausdruck NULL hin, statt 0 oder ''
2. das union ist vermutlich auch überflüssig

1. Der Ausdruck und die dem Druck zugrunde liegenden Daten sind ja zweierlei.
2. ich denke das das Union nicht überflüssig ist da vereinfacht:

SQL-Code:

select ConStant BetragH,Betrag BetragS from bedingung1
Union
select betrag BetragH, ConStant BetragS from bedingung2

Falls die Reportsoftware mit solchen nicht ganz einfachen Bedingungen nicht klarkommt, muß eben alles über einzelne Abfragen gelöst werden.

Gruß
K-H

P.S.
Eine Mischung von numerischen Werten und Strings verbietet sich natürlich.

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1455029)

1. Der Ausdruck und die dem Druck zugrunde liegenden Daten sind ja zweierlei.
2. ich denke das das Union nicht überflüssig ist da vereinfacht:

1.
ja, die Typen in der Tabelle wurden noch nicht preisgegeben oder?
Aber, wie baut den ein Union Statement seine Ergebnistypen zusammen? Baut bzw. bestimmt sie? Es wertet die Ergebnistypen des ersten Select aus und verwendet sie für das Ergebnis. Bis jetzt ergibt das für einen der beiden Saldenspalten immer einen String.
Nachfolgende Daten werden implizit dahin konvertiert.
(Dieses zwangläufige Verhalten zeigt auch noch eine mögliche Alternative per Union: ein 3.Statement hinzunehmen, das zu allererst die Typen definiert (ohne einen Datensatz zu liefern.)
2. Die Vermeidung des Union ist hier sicher nicht easy, vielleicht sogar nicht möglich. Da aber keine vollkommen verschiedenen Datenquellen genutzt werden, kann man es versuchen.
(Solange das Datenmodell und die DB unbekannt sind, ist es relativ müßig, sich diesen Kopf zu zerbrechen)

p.s.: Ich meinte Ausdruck im Sinne von Expression, nicht Report/Ausgabe
Der Typ der Originalspalte ist natürlich wichtig, aber nicht entscheidend, wenn er "unterwegs" verformt wird.