Str vs Replace

[MaggieMay]

Hi,

die Fehler sind dadurch erklärbar, dass das Komma beim Funktionsaufruf als Parameter-Trenner gilt, die Str-Funktion aber nur einen Parameter erwartet und nicht zwei.

Ansonsten bringt es nicht allzuviel, sämtliche Varianten durchzuprobieren, wenn es (wie im auslösenden Fall) darum geht, einen gültigen SQL-String zu erzeugen. Wie Klaus schon sagte, es kommt nicht darauf an was man sieht...
Ich hatte diese Tests bereits vor etlichen Jahren schon mal gemacht (und auch irgendwo/-wie dokumentiert) und mein Fazit dabei war, dass die Str-Funktion zu favorisieren ist. Wenn ich morgen noch etwas dazu finde, lasse ich es euch gerne wissen.

[Beaker s.a.]

Hallo,

@Klaus (#11)

das ist ja auch der Ausgangswert

Genau, darum ging es ja von Anfang an, weshalb ich auch nur diese Spalte betrachtet habe.

@Franz

ich glaube. die ganze Verwirrung kommt daher, dass nicht zwischen der internen Darstellung einer Zahl (die ja nicht "lesbar" ist) und der visuellen Darstellung (die für den User relevant ist) dieser Zahl unterschieden wird.

Ja, im Prinzip schon klar, aber wie wird den intern dargestellt? Entsprechend den Regionaleinstellungen (intern = sichtbar), oder immer mit Punkt.
Ich vermute dann eher Ersteres. Bei Letzterem würde dann ja die Umwandlung für SQL mit Str gar nicht nötig sein.

@Eberhard (#13)

Genau, denn eine SQL-Anweisung, die ja am Ende entsteht (oder Teile davon), ist ja nichts anderes als ein Text (Zeichenkette).

Das ist mir wohl bewusst; – es wird eine ZAHL generiert (SQL-konform), die als TEXT an SQL übergeben wird.

Eine Dezimalzahl (incl. Double, Single, Currency), die von außen kommt (aus Variable, Formularfeld, Arrayfeld) muss SQL-lesbar gewandelt werden

Ja, aber was kommt denn da von aussen? Entsprechend Regionaleinstellungen (Komma)?

Replace ist nicht wirklich ein Ersatz für Str

Entsprang meiner Unwissenheit (siehe OP). Und weil ich das bei mir nun ändern wollte habe ich mir die Str-Funktion noch Mal angesehen. Und dabei bin ich eben auf meine Eingangsfrage gestossen.

@MaggieMay

die Fehler sind dadurch erklärbar, dass das Komma beim Funktionsaufruf als Parameter-Trenner gilt, die Str-Funktion aber nur einen Parameter erwartet und nicht zwei.

Hatte ich schon im OP erwähnt.

gruss ekkehard

[DF6GL]

Hallo,

ich befürchte, da ist Vieles noch nicht klar:

Was wir brauchen im SQL-STRING, um dem SQL-Interpreter eine DEZIMAL-ZAHL anzubieten, die er als solche verarbeiten kann:

Eine Zeichenfolge, die aus dem Vorzeichen ("+" oder "-")  , den eigentlichen Ziffern (nicht ZAHLEN) , dem Dezimal-PUNKT (weil amerikanisches Format erforderlich ist) und den restlichen Ziffern.

Je nachdem, woher eine solche Zahl nun stammt (manuell im VBA-Editor eingeben --> 123.12 oder über einen Variableninhalt ---> dblMeineDblZahl , bzw. einem Textfeldinhalt-->  Me!Textfeld1), muss dies in den o. g. erforderlichen STRING umgewandelt werden, und zwar ohne Berücksichtigung der Regionaleinstellungen.

Weil STR() nun mehrere "Zahlen"-Darstellungen als Argument akzeptiert (wie bekannt) , liefert die Funktion nun einen String zurück, der die "Zahl" im Argument im amerikanischen Format (also mit Dezimal-PUNKT) darstellt und beim Zusammenbau des SQL-Strings geeignet ist.

Wird eine Variable vom Datentyp Double direkt (also ohne Wandlung mit einer Funktion) mit "&" in einen (SQL-) String eingebaut, so greift hier die interne Konvertierung ( CStr() )  in einen String, aber mit Berücksichtigung der Region-Einstellungen, was eben bei "deutsch" das Komma und nicht den Punkt ergibt und damit bei SQL einen Fehler verursacht.

Dim dblVar1 as Double, strSQL as String
dblVar1 = 12345.12   ' VBA spricht amerikanisch, deshalb würde hier ein Komma falsch interpretiert

STRSQL = "Select * from Tabelle1 where DBLZAHL = " & dblVar1 & " order by ID"
--->  Select * from Tabelle1 where DBLZAHL = 12345,12 order by ID"

STRSQL = "Select * from Tabelle1 where DBLZAHL = " & CStr(dblVar1) & " order by ID"
--->  Select * from Tabelle1 where DBLZAHL = 12345,12 order by ID"

stellt man hier in den Regionseinstellungen das Dezimaltrennzeichen auf den Punkt ein (und ändert auch das Tausender-Trennzeichen), so würde auch CStr() (und auch das erste Beispiel) das richtige Resultat liefern:

STRSQL = "Select * from Tabelle1 where DBLZAHL = " & CStr(dblVar1) & " order by ID"
--->  Select * from Tabelle1 where DBLZAHL = 12345.12 order by ID"


Wie wir nun zu dem SQL-geeigneten Ziffern-String kommen, ist erst mal egal.  Es bietet sich halt die STR()-Funktion an, weil sie immer das richtige Ergebnis liefert.

Entsprechend den Regionaleinstellungen (intern = sichtbar), oder immer mit Punkt.

Was hat das mit intern/sichtbar zu tun?

In den Regionaleinstellungen wird festgelegt, wie das Dezimal-Trennzeichen am entspr. Rechner auszusehen hat, wenn man eine Dezimal-Zahl (intern dargestellt bei Double als Gleitkommazahl (Basis, Mantisse, Exponent, oder bei Währung als Festkommazahl) anzeigt oder in einen String umwandelt.

Ja, aber was kommt denn da von aussen? Entsprechend Regionaleinstellungen (Komma)?

Es kommt von Dir (manuelle Eingabe in z. B. Form-Textfelder),  aus deinen Tabellen (entsprechend Datentyp) und ausgelesen mittels Recordset z. B. oder auch Dlookup, oder sonstigen Ergebnissen von Funktionen oder Ausdrücken...

Was auch schon erwähnt wurde:

Die "Hilfeleistung" des VBA-Interpreters (die automatischen internen Typkonvertierungen) bringen manchmal mehr Verwirrung/Unverständnis der Gesamtlage als sie nützen...


Als letzte Anmerkung:

Ich lasse mich jetzt intern in eine 2-m-Horizontallage konvertieren. 

[ebs17]

Ja, aber was kommt denn da von aussen?

Code [Auswählen] Erweitern

sSQL = "SELECT * FROM TabX WHERE FieldA = 2.34"

sSQL = "SELECT * FROM TabX WHERE FieldA = FieldB"

sSQL = "SELECT * FROM TabX WHERE FieldA = Time()"
Hier liegt ein Double-Wert innen im SQL-String vor, er wird über eine Konstante, ein Tabellenfeld oder über eine Funktion (die bei Jet-SQL über den Expression Service direkt auswertbar ist) übergeben. Hier ist keine explizite SQL-Formatierung notwendig, wie z.B. auch nicht bei Date-Werten.

Code [Auswählen] Erweitern

sSQL = "SELECT * FROM TabX WHERE FieldA = " & Str(dblVariable)
dblVariable ist ein Wert von außen und kann nicht von der Datenbankmaschine ausgewertet werden. Daher wird der Wert über die Stringzusammensetzung ausgewertet und dann erst an die SQL-Anweisung übergeben. Dazu ist dann eine SQL-konforme Formatierung notwendig. Auch hier hat man das gleiche Verhalten wie bei Date-Werten.

[Beaker s.a.]

Hallo Franz, hallo Eberhard,
Vielen Dank für Eure ausführlichen Erläuterungen zu so später Stunde.
Bezügl. SQL ist mir das alles klar, es geht aber doch nur um die Ergebnisse, die Str auswirft.
Ich habe so das Gefühl, dass ihr euch nicht auf mein Niveau runterdenken könnt ;-).

Wird eine Variable vom Datentyp Double direkt (also ohne Wandlung mit einer Funktion) mit "&" in einen (SQL-) String eingebaut, so greift hier die interne Konvertierung ( CStr() )  in einen String, aber mit Berücksichtigung der Region-Einstellungen, was eben bei "deutsch" das Komma und nicht den Punkt ergibt und damit bei SQL einen Fehler verursacht.

Das heisst doch, dass eine Variable den Punkt ja schon enthält (wegen Double). Dieser wird dann VBA-intern in ein Komma umgewandelt (wegen Regionaleinst.), dass ich dann wieder in einen Punkt umwandeln muss (wegen SQL). Dies habe ich vermutet, und kann ich auch verstehen.
Aber:

Weil STR() nun mehrere "Zahlen"-Darstellungen als Argument akzeptiert (wie bekannt) , liefert die Funktion nun einen String zurück, der die "Zahl" im Argument im amerikanischen Format (also mit Dezimal-PUNKT) darstellt und beim Zusammenbau des SQL-Strings geeignet ist.

Ausser der Darstellung als Zahl mit Punkt (amerikanisch) als String ("10.33").

Lasst es uns jetzt aber gut sein. War ein netter Exkurs, aber zurück zu Wichtigerem. Ich werde jetzt Mal meine Replaces durch Str ersetzen, dann werde ich ja sehen.
gruss ekkehard

[DF6GL]

Hallo,


noch ein Kommentar zu   "Das heisst doch, dass eine Variable den Punkt ja schon enthält (wegen Double)."

Eine solche Variable enthält nie einen "Punkt" (das ist ja ein Text-Zeichen) , sie enthält eine ZAHL (bei Double intern dargestellt durch eine Bitkombination, die sich aus Basis, Mantisse und Exponent des Zahlenwertes ergibt.)

Der Punkt wird erst dann "hinzugefügt", wenn der Variablen-Inhalt visuell ANGEZEIGT (auf dem Monitor oder Drucker) oder aber durch irgendeine Maßnahme (interne Konvertierung oder durch eine Konvertierungs-Funktion) in einen String umgewandelt wird. D. h. es können nur Strings(!) angezeigt (visuell dargestellt) werden (auch dann, wenn die Schreibmarke z. B. im VBA-Editor über einer Double-Variablen steht)..

Ausser der Darstellung als Zahl mit Punkt (amerikanisch) als String ("10.33")

Das ist auch nicht ganz richtig. Dieser Punkt im String wird in deutscher Umgebung (entspr. den Regionseinstellungen) als Tausender-Trennzeichen interpretiert und somit für eine Umwandlung nach Double schlichtweg ignoriert, so dass sich hier ein Wert von 1033 ergibt.


zufälliger Link:
http://de.ccm.net/contents/496-darstellung-von-ganzen-und-reellen-zahlen#darstellung-einer-naturlichen-zahl