[SQL] Ganzzahl ändern in Dezimalzahl mit 2 Nachkommstellen

[juergen]

Hallo zusammen,
so, habe einiges versucht Convert(xxx, SQL_Float), casten in allen Varianten, Decimal....
nichts geht.
Ich komme an marabus Vorschlag einfach nicht vorbei, denn dieser funktioniert! :thumb: Vielen Dank!
(ich frag mich nur, wie man da von selbst drauf kommen soll. :stupid: )
Wenn man sich in dem Referenz-Handbuch von der Datenbank durchwühlt, findet man mindesten 10 Varianten, wo man meinen könnte, dass das funktionieren sollte.
Naja, das ist wohl das Los von einem Anfänger.

Das nachfolgende verstehe ich auch überhaupt nicht...

Zitat:

Zitat von marabu

SQL-Code:

..as wert...

Was ist "wert"?
Ich habe jetzt:

SQL-Code:

SELECT (RIGHT(KtoRechWerte.Datum, 2) + '.' + SUBSTRING(KtoRechWerte.Datum, 5, 2) + '.' + LEFT(KtoRechWerte.Datum, 4)) , LTRIM(Personalstamm.PersNr), cast(round(cast(KtoRechWerte.Wert as float) /60, 2) as numeric(10, 2)) as Wert FROM KtoRechWerte, Personalstamm WHERE (KtoRechWerte.PersId = Personalstamm.Identifikation) AND...

Grüße aus Dortmund
Jürgen

[DeddyH]

Zitat:

Zitat von juergen

Was ist "wert"?

Das ist lediglich ein Alias für das berechnete Feld, damit es einen sprechenden Namen bekommt und somit bequem ansprechbar ist.

[marabu]

Hallo Jürgen,

mein Lösungsvorschlag ist kein Hexenwerk. Der SQL-Standard legt fest, dass arithmetische Operationen mit Integer-Werten einen Integer-Wert als Ergebnis haben. Da du auf die Nachkommastellen nicht verzichten willst, musst du einfach dafür sorgen, dass an der Division nicht nur Ganzzahlen beteiligt sind. Ich habe das aus didaktischen Gründen per CAST() gemacht. Alles andere dürfte deinen Versuchen recht ähnlich sehen.

Der Zusatz "as Wert" sorgt dafür, dass der im SELECT-Statement verwendete Ausdruck in der Ergebnismenge einen vernünftigen Namen trägt, über den du auch per FieldByName() zugreifen kannst.

In meinem Beispiel hatte ich einen Alias-Namen für die Tabelle vergeben. Diese Alias-Namen tragen sehr zur Lesbarkeit eines so umfangreichen Statement wie deinem bei:

SQL-Code:

SELECT (RIGHT(k.Datum, 2) + '.' + SUBSTRING(k.Datum, 5, 2) + '.' + LEFT(k.Datum, 4)), 
  LTRIM(p.PersNr), CAST(ROUND(CAST(k.Wert AS FLOAT) / 60, 2) AS NUMERIC(10, 2)) AS Wert 
FROM KtoRechWerte k, Personalstamm p
WHERE (k.PersId = p.Identifikation) 
  AND ...

Außerdem fällt mir auf, dass du ein Datum als String im Format 'YYYY-MM-DD' speicherst. Günstiger wäre die Speicherung im von Pervasive SQL unterstützten Datentyp DATE. Du kannst das auch nachträglich noch ändern:

SQL-Code:

ALTER TABLE KtoREchWerte MODIFY COLUMN Datum DATE

Das hätte den Vorteil, dass du das Format der Ausgabe mit SET DATEFORMAT = dmy einfach umstellen könntest, was dein Statement nochmal vereinfachen würde:

SQL-Code:

SELECT k.Datum, LTRIM(p.PersNr), CAST(ROUND(CAST(k.Wert AS FLOAT) / 60, 2) AS NUMERIC(10, 2)) AS Wert 
FROM KtoRechWerte k, Personalstamm p
WHERE (k.PersId = p.Identifikation) 
  AND ...

Wenn du das testen möchtest, dann sicher mit einer Kopie der Tabelle KtoRechWerte, die du leicht über Export und Import erstellen kannst.

Freundliche Grüße

[juergen]

Hallo,
habt vielen Dank für die Antworten und die für mich sehr hilfreichen Erklärungen. :thumb:

Das mit den Alias' ist dann ja ne schöne Erleichterung.
Nun, mir ist bewusst, dass ich aber um das Anlesen von Grundlagen nicht umhinkomme.
(Buch ist schon bestellt) :zwinker:

@ marabu
Das mit dem NICHT-Datumsformat in der Tabelle wurde aus Kompatibilitätsgründen zu verschiedenen DBMS, BS, Ländern, eingestellten DB-Normen und Import-Export-Interfaces/Funktionen so angelegt.
Durch Abbilden des Datums in einen String in dem Format YYYYMMDD (nicht YYYY-MM-DD) hat man letztendlich in der Summe mit weniger Problemen zu kämpfen.
Die Handhabung dieses Strings wird von nichts beinflusst, das Handling in Delphi oder woanders ist auch relativ einfach (wenn man sich dran gewöhnt hat) ;-)
Natürlich kanne es in gewissen Situaltionen anders herum hilfreicher sein. Es gibt also immer ein Für und Wider.

Allen ein schönes Wochenende!

[mkinzler]

Zitat:

Das mit dem NICHT-Datumsformat in der Tabelle wurde aus Kompatibilitätsgründen zu verschiedenen DBMS, BS, Ländern, eingestellten DB-Normen und Import-Export-Interfaces/Funktionen so angelegt.
Durch Abbilden des Datums in einen String in dem Format YYYYMMDD (nicht YYYY-MM-DD) hat man letztendlich in der Summe mit weniger Problemen zu kämpfen.

Und genau darum sollte man das Datumsformat nehmen und das DBMS, OS,Bibliotheken die Wandlung erledigen zu lassen. Bei Verwendung von Strings hast du zudem das Problem, das u.U. falsch sortiert wird, DBMS-interne Datumsroutinen nicht greifen.