Office: SQL Punkt statt Komma

Hallo,

wie wandele ich in einer Abfrage eine Zahl mit mit Dezimalkomma in Dezimalpunkt um? Die Blöde Formatfunktion will mir nicht gehorchen.

13,33 => 13.33

:)

 

Hallo,
schließe die Dezimalzahl in die Str Funktion ein.

Wenn Du gleich die Abfrage statt des nutzlosen Zahlenbeispiels gezeigt hättest, hätte man gleich einen genaueren Hinweis geben können.

 

Code:

 

Danke!

 

Wenn es wirklich um Zahlen geht, werden Eigenschaften wie Dezimal- und Tausendertrennzeichen durch die Ländereinstellungen des Rechners definiert. Also sollte man da in Abhängigkeit der gewollten Maßnahme arbeiten, wenn man den Zahlencharakter beibehalten will.

Format-Funktion, Replace & Co. machen Textverarbeitung und damit auch das Ergebnis zur Zeichenkette Zahl.

 

Aber die Ländereinstellungen greifen nun mal nicht in die Syntax einer SQL Anweisung hinein.
Die ist immer eine Zeichenkette und kümmert sich einen Dreck um die Ländereinstellung auf dem Rechner, auf dem sie zusammengestellt wird genauso, wie es ihr ziemlich egal ist, ob die Zeichen in der fraglichen SQL Anweisung (die zusammengesetzt wird), aus nummerischen oder alphanummerischen Quellen stammen.

Wenn ich Deinem apodiktischen "Also sollte man ..." nachspüre, dann meinst Du damit doch wohl nicht, dass man für die Dauer der Erzeugung einer SQL-Anweisung, in der die nummerischen Dezimalzahlen mit "." dargestellt werden müssen, den Rechner auf eine englische oder US-amerikanische Konfiguration umstellen sollte ???

 

Rechner umstellen? Nein.
Es gäbe aber Lösungen, die das codemäßig umsetzen können.

Vor dem Aktionieren sollte man sich bewusst und anderen klar machen,
- woher die Zahlen kommen,
- wie diese gelesen werden und
- wohin der Ausdruck gehen soll.
Erst dann würde man über Maßnahmen reden.

Dass man mit der gewünschten Umwandlung den Zahlencharakter verlassen und Text erzeugen wird, sollte einem aber grundsätzlich bewusst sein, Stichwort Datentypen.

 

Jede Menge Konjunktive.

Eine konkrete Lösung ohne replace() würde mich ja durchaus interessieren.


Eine SQL Anweisung ist Text und wird immer Text bleiben.
Und wie sich die nummerischen Werte, die darin repräsentiert sind, darstellen, wird vom Server vorgeschrieben, gegen den die SQL Anweisung abgefeuert wird.
Und damit muss der Mensch, der die Anweisung programmiert umgehen und darauf Rücksicht nehmen, genau so, wie er die Art und Weise berücksichtigen muss, wie in seiner lokalen Benutzerumgebung nummerische Werte dargestellt werden.

 

Eine konkrete Lösung für einen nicht näher und vollständig bezeichneten Fall?
Da kann ich mir etwas raussuchen?

Ein Fall, wo die Zahl Zahl bleibt (in schlüssiger Verwendung) und ein Dezimaltrenner-Wechsel nötig wäre, wäre Export/Import in eine CSV, um Daten zwischen englischsprachigen und deutschsprachigen Anwendungen zu tauschen.
Dort lasse ich eine Export-/Importspezifikation bzw. Schema.ini steuern, wie Daten zu lesen und zu schreiben sind, eine Textverarbeitung wäre da im Normallfall nicht notwendig.
Und genau: Der Inhalt einer CSV ist natürlich auch nur Text.

In meinem deutschsprachigen Access stehen Dezimalzahlen mit Komma in den Tabellen. SQL kann aber nur und ausschließlich mit der englischen Notation umgehen, das bemerkt man auch, wenn man solche Zahlen als Konstanten einbaut.
Mit der Übergabe der SQL-Anweisung an die Jet-Engine ist die Sprachumstellung intern bereits erledigt, ohne besonderes eigenes Zutun. Das Ergebnis wird mir dann wieder mit Komma angezeigt, wiederum ohne besonderes Zutun.

Es kommt also schon darauf an, was man macht.

 

\@Eberhard: Im Ernst, um eine SQL Anweisung zu formulieren, die einen Zahlenwert mit Punkt statt (wie wir es gewohnt sind) mit Komma zu übergeben, würdest Du statt des Einsatzes einer simplen replace() Funktion beim Erstellen des SQL Ausdrucks einen Ex- und Import über CSV empfehlen und vorziehen?
Das verstehe, wer will ...

 

Du baust Dir selber Luftschlösser, über die Du Dich wunderst.
Was ich tun würde, ist mit vollständigem Lesen obiger Beiträge zu ermitteln.

 

Du fällst mit Deinen Konjunktivismen hinter bereits klare Perspektiven zurück.

Nun gut: lassen wir es dabei.