TO_CHAR in MYSQL

[rap]

Hallo,

folgender Select funktioniert bei Oracle wunderbar:
select trim(to_char(floor(MPUNKT/100),'0000')) from TEST

Zur Erklärung:
Im Feld MPUKT steht eine 4-Stellige Zeichenfolge (z. B. 0102 oder 1210).
Das Ergebnis sind dann die ersten beiden Stellen mit zwei vorangestellten Nullen (also z. B. 0010 oder 0012).

MYSQL kennt aber TO_CHAR nicht, weil es (- wie ich gelesen habe -) nicht zum ANSI-SQL-STANDARD gehört.

Also müsste es doch irgendwie mit CAST gehen, welches aber den Wert nicht formatieren kann.

Am liebsten wäre mir eine ANSI-konforme Alternative zum oben genannten Select.

Vielen Dank

[dedlfix]

Hi!

MYSQL kennt aber TO_CHAR nicht, weil es (- wie ich gelesen habe -) nicht zum ANSI-SQL-STANDARD gehört.

Ob etwas zum ANSI-Standard gehört oder nicht, spielt eigentlich bei keinem DBMS eine Rolle für das (Nicht-)Implementieren. MySQL kennt jedenfalls die Funktion CHAR().

Am liebsten wäre mir eine ANSI-konforme Alternative zum oben genannten Select.

Warum?

Lo!

[rap]

Am liebsten wäre mir eine ANSI-konforme Alternative zum oben genannten Select.

Warum?

Weil ich noch nicht weiß, welche Datenbank ich verwenden werde bwz. damit ich leichter auf eine andere umsteigen kann.

Und wenn es ANSI-Standard ist, sollte es in den meisten Datenbanken implementiert sein.

[dedlfix]

Hi!

Weil ich noch nicht weiß, welche Datenbank ich verwenden werde bwz. damit ich leichter auf eine andere umsteigen kann.
Und wenn es ANSI-Standard ist, sollte es in den meisten Datenbanken implementiert sein.

Darauf sollte man sich nicht verlassen. Der Teufel steckt wie immer im Detail. Es geht ja schon los, dass jedes DBMS seine eigene Art hat, automatische IDs zu erzeugen. Auch sollte man nicht denken, einfach nur den Connect-String umstellen zu können und schon ist man auf eine andere Datenbank migriert. Das geht nur, wenn man nur recht einfache Abfragen macht. Der beste Kompromiss ist in meinen Augen immer noch eine Datenabstraktionsschicht in die Anwendung zu implementieren. Zur Anwendung hin gibt es definierte Schnittstellen (Funktionsaufruf - Parameter rein - Datenmenge raus). Zum DBMS hin hat man nun freie Hand und kann individuelle Features ausnutzen. Beim (selten vorkommenden) Wechsel des DBMS ändert man diese Schicht. Tests, dass mit dem neuen DBMS alles funktioniert wie gewünscht, muss man auf jeden Fall durchführen.

Lo!

[ChrisB]

Hi,

Im Feld MPUKT steht eine 4-Stellige Zeichenfolge (z. B. 0102 oder 1210).
Das Ergebnis sind dann die ersten beiden Stellen mit zwei vorangestellten Nullen (also z. B. 0010 oder 0012).

Du meinst also, die ersten beiden ab der ersten nicht-0-Stelle?

MfG ChrisB

[rap]

Du meinst also, die ersten beiden ab der ersten nicht-0-Stelle?

Nein, ich habe mich ungenau ausgedrückt.
Meine Zahl kann bis zu vier Stellen haben. Wenn die Zahl weniger als vier Stellen hat, sollen davor so viele Nullen aufgefüllt werden, dass ein 4-Stelliger String raus kommt.
Also
bei 1 soll 0001 raus kommen,
bei 10 -> 0010
bei 100 -> 0100
bei 1000 ->1000

Ich suche eine Alternative zu to_char, da ich MYSQL und FIREBIRD verwende, welche to_char nicht kennen.

Hier meine Selects, die bisher nur Zahlen ohne vorangestellte Nullen ausgeben:

Bei MYSQL:
SELECT DISTINCT floor( MPUNKT /100 )FROM TEST;

Bei FIREBIRD:
select distinct floor(cast(MPUNKT as integer)/100) from TEST;

[dedlfix]

Hi!

Meine Zahl kann bis zu vier Stellen haben. Wenn die Zahl weniger als vier Stellen hat, sollen davor so viele Nullen aufgefüllt werden, dass ein 4-Stelliger String raus kommt.

Dann suchst du also LPAD() und keinen Typecast.

Lo!

[rap]

Dann suchst du also LPAD() und keinen Typecast.

Ja genau, danke.

Ich hab es bei MYSQL und FIREBIRD getestet.
Bei MYSQL geht es problemlos.

_____________________________________________________________________________
Bei Firebird habe ich (mit dem Programm isql.exe) folgenden Befehl verwendet:
select distinct LPAD(floor(cast(MPUNKT as integer)/100),4,'0000') from TEST;

Die Datensätze werden zwar ausgegeben, aber es sind 327 leere Zeilen zwischen den Results. (Wirklich dreihundertsiebenundzwanzig was die Sache extrem unübersichtlich macht)

Entweder das von Firebird mitgelieferte Tool isql taugt nichts, oder mein Select-Befehl ist schlecht.

[Ilja]

yo,

select distinct LPAD(floor(cast(MPUNKT as integer)/100),4,'0000') from TEST;

du hast die spezifikation von LPAD (was übrigens auch oracle kennt) nicht richtig gelesen. was du brauchst ist LPAD(Wert,4,'0'), den die 4 in der funktion besagt ja schon, wie oft das Zeichen aufgefüllt werden soll.

Die Datensätze werden zwar ausgegeben, aber es sind 327 leere Zeilen zwischen den Results.

mit leer meinst du NULL werte ? Funktionen werden einen NULL werd zurück geben, wenn der inhalt NULL enthält, es sei den, man benutzt bestimmte funktionen für genau diesen fall. welche funktion das ist, hängt wieder vom jeweiligen dbms ab.

Ilja

[rap]

du hast die spezifikation von LPAD (was übrigens auch oracle kennt) nicht richtig gelesen. was du brauchst ist LPAD(Wert,4,'0'), den die 4 in der funktion besagt ja schon, wie oft das Zeichen aufgefüllt werden soll.

Danke für die Info.

Die Datensätze werden zwar ausgegeben, aber es sind 327 leere Zeilen zwischen den Results.

mit leer meinst du NULL werte ? Funktionen werden einen NULL werd zurück geben, wenn der inhalt NULL enthält, es sei den, man benutzt bestimmte funktionen für genau diesen fall. welche funktion das ist, hängt wieder vom jeweiligen dbms ab.

Ob es NULL-Werte sind, weiß ich nicht.

Hier habe ich mal die Ausgabe des Befehls ohne LPAD hoch geladen (http://raffe.lima-city.de/ohne_lpad.txt).

Und hier die Ausgabe (die ich nicht nachvollziehen kann) mit LPAD (http://raffe.lima-city.de/mit_lpad.txt)
PS: Bei der Ausgabe mit LPAD muss man einige hundert Zeilen nach unten scrollen um am Ende der Ausgabe zu sein...

[rap]

mit leer meinst du NULL werte ? Funktionen werden einen NULL werd zurück geben, wenn der inhalt NULL enthält, es sei den, man benutzt bestimmte funktionen für genau diesen fall. welche funktion das ist, hängt wieder vom jeweiligen dbms ab.

Ich glaube, das ist nur ein Bug bei isql.exe (welches bei Firebird dabei ist).
Denn wenn ich mich mit einem grafischen Tool über jdbc verbinde sieht das ganze so aus:

[Vinzenz Mai]

Hallo,

Ich glaube, das ist nur ein Bug bei isql.exe (welches bei Firebird dabei ist).

vielleicht auch nicht.
Textausgaben neigen dazu für (VAR)CHAR-Spalten soviele Zeichen als Breite zu nehmen, wie für die Spalte deklariert sind, das könnten bei LPAD() viele sein. Standard ist inzwischen 255 Zeichen, es könnten auch 32000 sein. Das hängt bei Firebird von der Deklaration der Funktion LPAD() ab. Wie sieht die Deklaration von LPAD() bei *Dir* aus?

Freundliche Grüße

Vinzenz

[rap]

Ich glaube, das ist nur ein Bug bei isql.exe (welches bei Firebird dabei ist).

vielleicht auch nicht.
Textausgaben neigen dazu für (VAR)CHAR-Spalten soviele Zeichen als Breite zu nehmen, wie für die Spalte deklariert sind, das könnten bei LPAD() viele sein. Standard ist inzwischen 255 Zeichen, es könnten auch 32000 sein. Das hängt bei Firebird von der Deklaration der Funktion LPAD() ab. Wie sieht die Deklaration von LPAD() bei *Dir* aus?

Hallo Vinzenz,
wie meinst du das mit der Deklaration von LPAD bei *MIR*?
Ich habe nichts weiter gemacht, als

• Firebird installiert

• die Tabelle in einer vorhandenen Testdatenbank erstellt:
  CREATE TABLE TEST(MPUNKT VARCHAR(4));

• Daten in die Tabelle eingefügt:

--Beispiel-Insert  
INSERT INTO TEST (MPUNKT) VALUES('0102');

-und folgenden Select
select distinct LPAD(floor(cast(MPUNKT as integer)/100),4,'0') from TEST;
 ausgeführt.

[Vinzenz Mai]

Hallo,

wie meinst du das mit der Deklaration von LPAD bei *MIR*?

wie in http://www.firebirdsql.org/refdocs/langrefupd21-udf-lpad.html, erläutert, war das erste was mir in PDF-Form über den Weg lief. Ohne Hinweis auf den Status als "deprecated"

Dennoch gilt im Prinzip immer noch das Gleiche. Schau Dir den Tipp im blauen Kasten von

http://www.firebirdsql.org/refdocs/langrefupd21-intfunc-lpad.html

an.

Freundliche Grüße

Vinzenz