SQL-Abfrage formatiert ausgeben

[waldforest]

Über eine Query - SQL-Abfrage ziehe ich mir Summen über meine Verkäufe und zeige diese über ein GRID an.

Das Formular beinhaltet unterschiedliche Abfragen, bei denen sich auch die Spalten ändern.
Gerne würde ich die Spalten formatiert anzeigen, z.B. in Currency etc.

z.B.

Code:

 
      WITH zrdnlyqry_Verkauefe do
      begin
       Active := False ;
       SQL.Clear;SQL.Add(     'SELECT');
       SQL.Add(     '   A.ARTIKEL_NR,');
       SQL.Add(     '   sum( OA.ARTIKEL_PREIS_D ) AS Sum_Umsatz,');
       SQL.Add(     '   sum( OA.ARTIKEL_EK_PREIS ) AS Sum_EK,');
       SQL.Add(     '   sum( OA.ARTIKEL_MENGE ) AS Sum_Anzahl,');
       SQL.Add(     '   CAST(( 100 *( 1 - SUM( OA.ARTIKEL_EK_PREIS ) ) / IIF( SUM( OA.ARTIKEL_PREIS_D ) = 0 ,0.01 , SUM( OA.ARTIKEL_PREIS_D ) ) ) as decimal( 6 , 2 ) ) AS ProzWert');
       SQL.Add(     ' FROM')
    :
    : 
    :
;

Wie kann ich nach Abfrage die gelesenen Spalten formatieren dass z.B. ?
SUM_Umsatz als Currency ausgegeben wird.
Leider wird auch der CAST-Wert nicht in Decinmal( 6,2 ) ausgegeben einige Ergebnisse weisen nur eine Dezimalstelle andere gar keine aus.

Wie beschrieben möchte ich die Query auf dem Formular dynamische nutzen um hier ein Standardformular mit unterschiedlichen Abfrage zu füttern.

[waldforest]

Hallo,
habe dann doch noch die Lösung gefunden. Vielleicht suchen ja auch Andere danach.

Code:

TNumericField(FieldByName('Sum_Umsatz')).DisplayFormat := '#0.00 €';
 TNumericField(FieldByName('Sum_EK')).DisplayFormat := '#0.00 €';
 TNumericField(FieldByName('ProzWert')).DisplayFormat := '#0.00 %';

Dennoch verstehe ich nicht warum CAST keinen Dezimalwert ausgibt)

[mkinzler]

Weil das Ergebnis Delphiseitig als Float aufgefasst wird.

[Dejan Vu]

Deine Query liefert Dezimalwerte (ob nun als decimal oder float ist egal). Dein Programm stellt diese Werte dar. Ohne explizite Angabe des Formats wird eine Zahl so genau wie nötig dargestellt. 7.00000 ist eine 7 und 1.230000000 eine 1.23 . Das ist auch vollkommen korrekt.

In einer Query bzw. mit den SQL-Datentypen 'Numeric' und 'Decimal' kannst Du die maximale Genauigkeit der internen Speicherung ('Auf 2 Nachkommastellen, 10 Stellen insgesamt') angeben, mit der *Darstellung* hat das nichts zu tun (Du kannst eine Decimal(10,2)-Zahl auch mit 3 Nachkommastellen ausgeben. Dann ist die letzte Nachkommastelle immer eine 0, aber es geht.

Erst mit einer Formatanweisung kannst du fixe Vor- oder Nachkommastellen angeben (wenn Du das möchtest).

Ich bevorzuge auch die Tausendertrennzeichen, weswegen mein bevorzugtes Format '#,0.00' ist.

[jobo]

Zitat:

Zitat von waldforest (Beitrag 1311630)

Wie beschrieben möchte ich die Query auf dem Formular dynamische nutzen um hier ein Standardformular mit unterschiedlichen Abfrage zu füttern.

Wenn es dynamisch sein soll, kannst Du direkt im SQL ein Cast auf Text versuchen. Dabei werden die Standard Settings verwendet (Decimaltrennzeichen usw.) Das macht allerdings nur Sinn, wenn es um readonly Daten geht.

Code:

cast(22.5 as varchar(50))

Leider hat man glaub ich keine Möglichkeit, das explizit mit einer Formatmaske zu versehen. Vielleicht findest Du dazu aber eine brauchbare UDF.

[mkinzler]

Ich würde Formatierungen nicht in der Abfrage, sondern bei der Anzeige durchführen.

[jobo]

Ich würde es auch nur unter gewissen Umständen machen, so hab ich es ja auch geschrieben. Der TE kann es vielleicht selbst beurteilen, ob es für Ihn in Frage kommt. Ein Hindernis ist ja hier leider die "dünne" Ausstattung bei Firebird.

Warum würdesst Du es nicht machen?

[haentschman]

Zitat:

Warum würdesst Du es nicht machen?

...weil nur die Anzeige für die Darstellung verantwortlich ist. Beispiel Datum: Das liegt in der DB als TDateTime. Letztendlich entscheidet die Anzeige ob es im Englischen oder Deutschem Format angezeigt wird. Du würdest auch keine 2 SQL machen um den Datumsstring schon formatiert aus der DB zu holen oder? :P

[jobo]

Tja, also ich kann ohne Probleme einen Preis oder eine Summe dynamisch per SQL ausgeben und meinetwegen auch eine Währung berücksichtigen, ähnlich geht es bei Datumsangaben, kommt halt auch auf die Fähigkeiten des DB Systems an, wie schon gesagt.

Die Vorgabe des TE war ja ein Formular für unterschiedliche SQL Statements zu verwenden.
Jetzt kann er entweder eine Feldverwaltung mit Formatierung einbauen oder aber im einzigen Teil, der eh dynamisch ist, direkt für eine richtig formatierte Ausgabe sorgen.

Natürlich gibt es Direktiven wie "weil nur die Anzeige für die Darstellung verantwortlich ist" nicht ohne Grund, aber die sind kein Selbstzweck. In einem überschaubaren Rahmen finde ich eine Lösung mit SQL Formatierung vollkommen okay.

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1311669)

Zitat:

Warum würdesst Du es nicht machen?

...weil nur die Anzeige für die Darstellung verantwortlich ist. Beispiel Datum: Das liegt in der DB als TDateTime. Letztendlich entscheidet die Anzeige ob es im Englischen oder Deutschem Format angezeigt wird. Du würdest auch keine 2 SQL machen um den Datumsstring schon formatiert aus der DB zu holen oder? :P

Jain, ich hab die Situation, das ein Std-Schreiben aus der DB gefüttert wird, da wird das Datumsformat über den Standort in der Queryausgabe gesteuert. Da ich aber eh eine Unterscheidung deutscher/englischer Brief habe, wäre es zu überlegen, dort das Datum zu formatieren.

Gruß
K-H

[haentschman]

Hallo,

Zitat:

Da ich aber eh eine Unterscheidung deutscher/englischer Brief habe, wäre es zu überlegen, dort das Datum zu formatieren.

Sicher gibt es verschiedene Ansichten. Persönlich würde ich die DB zum Halten der Daten verwenden und dem Report, der den Brief generiert, die Formatierung überlassen. Imho kann der das besser... :P

[p80286]

Hab ich was von "Report" geschrieben?:shock:
es ist Word, und die Zicke von dem zu überzeugen was man gerne hätte ist doch recht aufwendig.
Darum auch die Tricksereien mit der Abfrage und dem Ausgabeformat.

Gruß
K-H

P.S.
in absehbarer Zeit wir bei uns offizell auf ISO-Format umgestellt, dann stellt sich auch diese Frage nicht mehr!