Darstellung einer Zahl im DBGrid

[khh]

hallo zusammen,
ich habe eine EAN13 in einem DB-Feld vom Typ char().
Funktioniert soweit wunderbar.
Die Daten werden im DBGrid ordentlich dargestellt.
Allerdings werden diese EANs auch alphanummerisch sortiert.
Mein Versuch die Nummern numerisch zu sortieren scheitert bisher :-(
Ich habe im SQl-Statement ein

Code:

cast(f.artnr as float) as  artnr

eingefügt,da ich der Meinung war der Wertebereich ist so ausreichend.
Formatiert wird die GRID-Ausgabe mit '############0'
Leider wird so aus einer gültigen EAN "4008400401027"
die formatierte Zahl 4008400388096 :-(
Hat hier jemand ne Erklärung?

[hhcm]

Welche DB Engine verwendest du denn? SQL ist ziemlich vielfältig ;)

Abgesehen davon, wie kann denn eine EAN falsch sortiert werden? Selbst wenn es nicht numerisch ist?

[khh]

Zitat:

Zitat von hhcm (Beitrag 1158907)

Welche DB Engine verwendest du denn? SQL ist ziemlich vielfältig ;)

Abgesehen davon, wie kann denn eine EAN falsch sortiert werden? Selbst wenn es nicht numerisch ist?

sorry,
firebird 2.1 zugriff über ZEOS

naja, ist eben ein Unterschied ob numerisch oder alphanumerisch sortiert wird.
EDIT:
ibexpert kommt zum gleichen Ergebnis,
aus einer gültigen EAN "4008400401027" wird
4008400388096

[DeddyH]

Aber doch nur bei unterschiedlicher Stringlänge, oder täusche ich mich gerade?

[edit] Wie ist es denn ohne Cast und stattdessen mit LPAD?

SQL-Code:

LPAD(artnr, 20) as artnr

[/edit]

[khh]

Zitat:

Zitat von DeddyH (Beitrag 1158912)

Aber doch nur bei unterschiedlicher Stringlänge, oder täusche ich mich gerade?

was meinst du mit unterschiedlicher stringlänge ?

[DeddyH]

Damit meine ich, dass 123 nummerisch bewertet größer ist als 42, alphanumerisch aber nicht. Hast Du mein Edit oben gesehen?

[hhcm]

Also er sagt EAN13 = 13 Ziffern. Ich verstehe gerade nicht warum das fehlerhaft sortiert werden sollte?

[shmia]

Wie wäre es damit:

SQL-Code:

SELECT RightString('0000000000000'+ArtNr, 13) AS SortFeld, * FROM EanTabelle
ORDER BY 1

Für die Funktion RightString() muss im Firebird 2.1 Dialekt die passende Funktion nachgeschlagen werden.
ORDER BY 1 bedeutet es wird nach dem 1. Feld sortiert.
Eventuell muss zusätzlich noch die RTrim()-Funktion verwendet werden, weil ein Char(13)-Feld wahrscheinlich anhängende Leerzeichen haben kann

SQL-Code:

SELECT RightString('0000000000000'+RTrim(ArtNr), 13) AS SortFeld, * FROM EanTabelle
ORDER BY 1

[DeddyH]

Dürfte das nicht mein LPAD von oben sein?

[khh]

Zitat:

Zitat von DeddyH (Beitrag 1158915)

Damit meine ich, dass 123 nummerisch bewertet größer ist als 42, alphanumerisch aber nicht. Hast Du mein Edit oben gesehen?

ja, so ist es, und so gefällt es den meisten Kunden nicht.

LPAD funktioniert, ich danke dir.

Kannst du mir das vieleicht noch erklären?

Muss mich korrigieren,
die Sortierung ist mit LPAD auch alphanumerisch, kann ich mir also sparen :-(

[DeddyH]

Ganz einfach: LPAD füllt links mit Leerzeichen (oder einem optional anzugebenden) bis zur angegebenen Länge auf. Und da das Leerzeichen einen kleineren ASCII-Wert als '0' hat, stimmt anschließend die alphanumerische mit der nummerischen Sortierung überein. Für Details zu der Funktion siehe firebirdsql.org.

[khh]

Zitat:

Zitat von DeddyH (Beitrag 1158920)

Ganz einfach: LPAD füllt links mit Leerzeichen (oder einem optional anzugebenden) bis zur angegebenen Länge auf. Und da das Leerzeichen einen kleineren ASCII-Wert als '0' hat, stimmt anschließend die alphanumerische mit der nummerischen Sortierung überein. Für Details zu der Funktion siehe firebirdsql.org.

ok, dann muss ich wohl die Stringlänge anpassen, da das Feld an sich schon char(20) ist.

aber weshalb funktioniert cast nach float nicht??

[DeddyH]

Ich habe den Wertebereich von Firebird-Float nicht im Kopf, aber möglicherweise kommst Du mit Deinen Zahlen da in einen Grenzbereich, wo es ungenau wird (das haben Fließkommazahlen ja leider so an sich).

[Iwo Asnet]

Sagt mal, ist es nicht ein wenig verwunderlich, wenn ein EAN-Code, der aus ZEICHEN besteht, als FLOAT in einer DB landet? Das ist grenzwertig gefährlich.

[DeddyH]

Zitat:

ich habe eine EAN13 in einem DB-Feld vom Typ char().

Wo landet da ein Float in der DB? Der Cast war ein Versuch beim Auslesen für die Sortierung.

[khh]

Zitat:

Zitat von Iwo Asnet (Beitrag 1158939)

Sagt mal, ist es nicht ein wenig verwunderlich, wenn ein EAN-Code, der aus ZEICHEN besteht, als FLOAT in einer DB landet? Das ist grenzwertig gefährlich.

die EAN steht als String in einem 20 Zeichen grossen char()- Feld in der DB

[Sir Rufo]

Zitat:

Zitat von Iwo Asnet (Beitrag 1158939)

Sagt mal, ist es nicht ein wenig verwunderlich, wenn ein EAN-Code, der aus ZEICHEN besteht, ...

Streng genommen besteht der EAN-Code aus Ziffern ;)

[Iwo Asnet]

Zitat:

Zitat von Sir Rufo (Beitrag 1159026)

Zitat:

Zitat von Iwo Asnet (Beitrag 1158939)

Sagt mal, ist es nicht ein wenig verwunderlich, wenn ein EAN-Code, der aus ZEICHEN besteht, ...

Streng genommen besteht der EAN-Code aus Ziffern ;)

Strenger genommen besteht der EAN-Code aus Zeichen, die auf die Ziffern beschränkt sind. :mrgreen:

Zitat:

Zitat von khh (Beitrag 1159018)

die EAN steht als String in einem 20 Zeichen grossen char()- Feld in der DB

Und dann wird er als FLOAT gecastet und man wundert sich, das die letzten Stellen flöten gehen?

Zitat:

Zitat von khh (Beitrag 1158911)

aus einer gültigen EAN "4008400401027" wird
4008400388096

Versuche es mit numeric(13), dann bleiben alle Stellen erhalten. Wenn Firebird das kann.

Hier mal der Grund:

Zitat:

Zitat von Firebird 2.0 Online Manual

FLOAT specifies a single-precision, 32-bit datatype with a precision of approximately 7 decimal digits.

Stimmt sogar auffallend.

[khh]

>> Und dann wird er als FLOAT gecastet und man wundert sich, das die letzten Stellen flöten gehen?

wenn dem so wäre hätte ich die Erklärung die ich suche, dem ist aber nicht so, die letzen Stellen werden durch andere Ziffern "ersetzt" :-(

[DeddyH]

Ich dachte, mit dem LPAD sei das Problem gestorben :gruebel:

[Furtbichler]

Zitat:

Zitat von khh (Beitrag 1159172)

>> Und dann wird er als FLOAT gecastet und man wundert sich, das die letzten Stellen flöten gehen?

wenn dem so wäre hätte ich die Erklärung die ich suche, dem ist aber nicht so, die letzen Stellen werden durch andere Ziffern "ersetzt" :-(

Da wird nichts 'ersetzt', na ja irgendwie schon. FLOAT ist nur auf 7-8 Stellen genau. Also kannst Du nicht jede 13 stellige Zahl darstellen. In der Folge wird logischerweise "aus einer gültigen EAN '4008400401027' '4008400388096'.
Die Zahl 4.008.400.401.027' hat als FLOAT das gleiche Bitmpuster wie 4.008.400.388.096.
Das gleiche dürfte für z.B. 4.008.400.389.123 gelten.

Und ich würde nicht einfach dagegen halten, sondern einfach ausprobieren (geht schneller)

Code:

select cast ('123456789012' as float), cast ('123456789012' as numeric(13))

[khh]

>>Die Zahl 4.008.400.401.027' hat als FLOAT das gleiche Bitmpuster wie 4.008.400.388.096

DAS ist die Erklärung die ich gesucht habe.
EDIT :cast ('123456789012' as numeric(13)) funktioniert ebenfalls

Ich danke euch

Gruss KHH