none
numeric, decimal und float: Warum gibt ein numeric-Feld ein Fehler bei SSRS mit NULL-Inhalten aus? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    bei der Felddefintion habe ich den Buchungsbetrag als numeric (18,2) definiert. Bei der SSRS Abfrage mittels

    =Sum(iif(trim(Fields!Datenart.Value)="I",Fields!Buchungsbetrag.Value,0))

    erhalte ich eine ERROR-Meldung, wenn NULL-Werte bei den Gruppierungen zwischen den Datenarten ins Spiel kommen. Genauigkeit hin oder her: Als ich das Feld in der SQL-Abfrage als float umgewandelt habe war der Fehler weg. Bei der richtigen Auswahl Felddefintion tu ich mich sehr schwer, da mir oft nicht klar ist was noch für Folgefehlen kommen können. Ich will lediglich Zahlen und Texte auswerten.

    FRAGE:

    Was nimmt man da üblicherweise für Buchungsbeträge die 2 stellig sind und warum kommt der Fehler?

    Warum muss ich ein "trim" bei der Datenart als nchar(6) definiert setzten, wenn nur ein "I" oder "P" oder ev. später "1.Lauf" enthalten ist. Wie umgeht man dies Problem mittels richtiger Felddefinition? 

    Vielen Dank für Eure Erklärungen

    Donnerstag, 14. Mai 2020 15:14
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden
    Hallo zusammen, ich habe heute eben nochmals das Wertfeld mit den drei Definitionen getestet. Numeric UND decimal geben einen Fehler zurück, wobei hingegen float läuft. Ist es denn grundsätzlich zu empfehlen oder ein Problem alle Betragsfelder als float zu nutzen oder wie können sich hier erfahrungsgemäß in Berechnungen Unschärfen ergeben? NULL-Werte wird es immer mal wieder im Vergleich geben.
    Freitag, 15. Mai 2020 06:50
    |
  • Question
    Anmelden
    1
    Anmelden

    Das Problem liegt eher an SSRS als am SQL-Server.
    Hier kommt dann u.U. die .Net Runtime ins Spiel und SSRS erwartet kein Decimal/Numeric.

    Hier kannst du wohl nur eine Umgehung machen.

    a) du stellst eine View für SSRS bereit in dem du das Feld per "coalesce(Feld,  0)" mit einem gültigen Wert versiest.
    b) erweitere dein IIF-Kontruct um "and Fields!Buchungsbetrag.Value is not null", falls SSRS dies versteht.

    Freitag, 15. Mai 2020 07:31
    |
  • Question
    Anmelden
    1
    Anmelden

    Hi,
    Unschärfen gibt es nicht. Man muss nur verstehen, dass sich binäre Gleitkommazahlen und eine Dezimaldarstellung von Gleitkommazahlen nicht in jedem Fall genau umwandeln lassen. Das ist vergleichbar mit einer Addition von 1/3+1/3+1/3, was als Ergebnis 1 ergibt, wogegen die Addition von 0,33+0,33+0,33 nur 0,99 ergibt. Egal wie lang die Mantisse ist, wird es da immer eine "Ungenauigkeit" bei der Umwandlung in Dezimaldarstellung geben. Umgehen kann man dieses Problem nur mit Runden. Aber auch dabei ist aufzupassen. Buchhalterisches Runden gibt ein statistische Schieflage, die dann zu Differenzen führen kann.

    Unklar ist auch, warum Nullwerte zulässig sind. Nullwerte sind meist nur dann sinnvoll, wenn damit eine zusätzliche Information "verschlüsselt" werden soll, z.B. Wert ist nicht erfasst und muss noch erfasst werden. Wenn diese Unterscheidung nicht erforderlich ist, sollte kein Null zulässig sein und z.B. ein Standardwert wie 0 eingetragen werden.

    Der Bezeichner "Buchungsbetrag" lässt vermuten, dass es sich um genaue Geldbeträge handelt. Und in solchem Fall sollte immer unbedingt Numeric, decimal bzw. money verwendet werden.

    Falls es doch bei der Zulässigkeit von Null bleiben muss, ist in die Summenformel eine zusätzliche Prüfung auf Nicht-Null einzufügen.

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks


    Freitag, 15. Mai 2020 07:58
    |
  • Question
    Anmelden
    1
    Anmelden

    "Unklar ist auch, warum Nullwerte zulässig sind. Nullwerte sind meist nur dann sinnvoll, wenn damit eine zusätzliche Information "verschlüsselt" werden soll, z.B. Wert ist nicht erfasst und muss noch erfasst werden. Wenn diese Unterscheidung nicht erforderlich ist, sollte kein Null zulässig sein und z.B. ein Standardwert wie 0 eingetragen werden."

    Genau dafür ist NULL statistisch relevant, da bei Aggregaten ungleich SUM die NULL nicht gewertet wird, während die 0 z.T. massiven Einfluss hat. Eine "Verschlüsselung" ist dies nur insoweit als das dies der Bedeutung "Nicht vorhanden" entspricht. Auch in Excel z.B. werden leere Zellen nicht bewertet.

    Bzgl. SSRS halte ich es daher für einen Fehler, da sich die Bedeutung von NULL zwischen float und numeric/decimal nicht unterscheidet.
    Aber anscheinend kann SSRS mit NULL bei decimal/numeric nicht umgehen.
    Wie man da dann z.B. eine AVG-Formel realisieren will, bei der NULL benötigt wird, entzieht sich mir dann.

    Allerdings kommt es bei statistischen Auswertung nicht so sehr auf die oben ausgeführten Unschärfen an.
    Bei einer Umwandlung in float (cast ohne Rundung!), Aggregierung und anschließender Rundung kommt es in der Summe nur sehr selten zu der berümten 0,01€-Differenz.
    Statistisch ist das dann eher bedeutungslos.


    Freitag, 15. Mai 2020 08:21
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,
    "Auch in Excel z.B. werden leere Zellen nicht bewertet." Mein Excel 2016 hier benutzt in der SUMME-Funktion den Wert 0 für eine leere Zelle. Das lässt sich leicht überprüfen, wenn man die Summe über einen Bereich mit nur leeren Zellen berechnen lässt. Ein Vergleich einer typ-unsicheren Datenbank wie Excel mit einer typsicheren Datenbank wie SQL Server widerstrebt mir. Wenn ich z.B. den Auftrag bekomme, eine vorhandene Excel-Tabelle in eine typsichere Datenbanktabelle zu überführen, dann bekomme ich Stress. Da steht dann oft in einer Termin-Spalte in Excel "Sofort", "nächstes Quartal", "35. KW" usw.

    Wenn "Fields!Buchungsbetrag" Null ist, dann kommt ein Fehler, wenn dann auf eine bei Null nicht vorhandene Eigenschaft zugegriffen werden soll, z.B. "Fields!Buchungsbetrag.Value". So etwas muss der Programmierer abfangen und darf nicht darauf vertrauen, dass zur Laufzeit etwas Zufälliges passiert, was nicht zu einem abnormalen Abbruch führt.

    Übrigens kann auch eine Sum-Funktion im SSRS mit Null umgehen, indem in diesem Fall der Wert 0 angenommen wird. Wenn ich jedoch in den Argumenten der Sum-Funktion auf Eigenschaften des Feld-Objektes zugreife ("Fields!Buchungsbetrag.Value"), kracht es, wenn es keinen Feldinhalt gibt, da Null bzw. DBNull geliefert wird.

    Unschärfen können sich problemlos ergeben, wenn die Rundungen für Einzelbeträge und auch für aggregierte Beträge ausgeführt wird und nicht ausschließlich an einer Stelle. In solch Zustand kann man schnell geraten, wenn Zwischenwerte gerundet werden (z.B. Mehrwertsteuer buchhalterisch gerundet pro Einzelbetrag) und dann mit diesen gerundeten Werten aggregiert wird und parallel dazu z.B. Brutto- bzw. Nettosummen gebildet werden, von denen dann die Mehrwertsteuer berechnet wird. Aus diesem Grund sollten solche Anwendungen immer mit Ganzzahl-Ablage arbeiten, wie numeric(18,2).

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Samstag, 16. Mai 2020 19:14
    |
  • Question
    Anmelden
    0
    Anmelden

    Wie ich schon sagte, bei SUM-Agregaten spielt NULL bzw. leerin Excel natürlich keine Rolle.
    Allerdigs bei Mittelwert/Anzahl usw. ist "Leer" mit NULL gleichzusetzen.
    Eine Annahme von "0" führt in diesem Fall zum falschen Ergebnis, deshalb gibt's ja NULL bzw. in .Net DBNull.

    Das Problem von NULL bzw. DBNull muss allerding SSRS genauso für Decimal/Numeric behandeln wie für Float/Double, denn da ist der Fehler ja wohl weg. Selbst berechnete Spalten im DataTable-Object von .Net kommen mit DBNull zurecht.

    Also sollte man da bzgl. SSRS ruhig mal einen Fehler melden, denn der Programmierer ist ja da nun mal Microsoft und fängt den Fehler nicht ab.
    Zumal man bei Zugriff auf die Eigenschaft ".Value" keinen Null-Referenz Fehler erhält, die Spalte ist ja schließlich da, sondern die falsche Verwendung von DBNull.

    Und was die Rundung angeht, so sprach ich ja auch von End- und nicht von Zwischenergebnissen;-).



    Sonntag, 17. Mai 2020 13:06
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen und danke für die Erläuterungen!!! 

    Ich arbeite öfter mit Kreuztabellen, wo man NULL-Werte erzeugt, die ich dann ev. aggregiere oder in Plan/Ist gegenüberstelle. In der Tat habe ich dies sonst immer mit einer Funktion IsNull abgefangen, was die Textfelder mit langen Formel nicht unbedingt übersichtlicher macht.

    Das könnte ich mir ja so sparen. Im Grunde die Frage, ob es mich ev. einholt, wenn ich grundsätzlich Betragsfelder als float definiere statt numeric oder Decimal (18,2) und so weiterarbeite und mir die Funktion spare? 

    Dienstag, 26. Mai 2020 15:14
    |
  • Question
    Anmelden
    1
    Anmelden
    Solange die Werte beim Import nicht gerundet werden und das Runden sich auf die Aggregate beschränkt gibt es kaum ein Problem (s.o.).
    Mittwoch, 27. Mai 2020 06:47
    |