DB2 und Concat von Strings?

[LordCinimod]

Moin ,

ich habe da mal eine Frage zu SQL.
Ich wollte gerade auf der System i in einer Tabelle zwei char Felder miteinander verbinden, dabei sollten die Felder durch ein Leerzeichen getrennt werden.

Beim MS-SQL Server mache ich das ja mit einem + Zeichen
Beispiel:

select vorname, nachname, vorname + " " + nachname as name from ..

unter My-SQL läuft das ja mit concat:

select vorname, nachname, concat(vorname, " ", nachname) as name from ..

Auf der System i geht das ja so anscheinend nicht, jedenfalls bekomme ich da dann einen Fehler geworfen. Ich habe es dann einmal so probiert:

select vorname, nachname, concat(concat(vorname, " "), nachname) as name from ..

aber optimal finde ich das nicht. Gibt es da noch eine andere Möglichkeit?

Grüße
Dominic

[Fuerchau]

Für Standard-SQL lautet die Syntax:

Feld1 concat feld2 concat feld3 ..... concat feldn

Die Funktion Concat kennt nur 2 Argumente.
Dann wäre das so:
concat(Feld1, Feld2)
concat(Feld1, concat(feld2, feld3))

Ansonsten gibt es ja eigentlich das SQL-Referenz-Handbuch zum Download als PDF.
Das finde ich immer wieder sehr hilfreich.

[LordCinimod]

Das concat nur 2 Argumente kennt habe ich ja schon festgestellt! Deswegen ja auch das concat(concat(.... Beispiel.

In der Referenz habe ich auch schon geschaut aber nichts zu gefunden, außer eben das Concat hier nur 2 Argumente akzeptiert.

So wirklich neues hast du nun nicht geschrieben, oder?
Ich habe ja danach gefragt ob es einen anderen Weg gibt um das nicht so umständlich und verschachtelt schreiben zu müssen.

[BenderD]

Das concat nur 2 Argumente kennt habe ich ja schon festgestellt! Deswegen ja auch das concat(concat(.... Beispiel.

In der Referenz habe ich auch schon geschaut aber nichts zu gefunden, außer eben das Concat hier nur 2 Argumente akzeptiert.

So wirklich neues hast du nun nicht geschrieben, oder?
Ich habe ja danach gefragt ob es einen anderen Weg gibt um das nicht so umständlich und verschachtelt schreiben zu müssen.

... les doch mal die Antworten und die Referenz genau, da ist doch alles drin, auch ohne schachteln!
Concat ist auch Operator!!!
select 'a' concat 'b' concat 'c'
from sysibm.sysdummy1

oder auch

select 'a' || 'b' || 'c'

hiran ist allerdings blöd, dass das Pipe Zeichen je nach CCSID auch als

select 'a' !! 'b' !! 'c'

erscheint.

D*B

[Fuerchau]

Ich kann mich Dieter nur anschließen:

"Feld1 concat feld2 concat feld3 ..... concat feldn"

war meine Antwort.

[LordCinimod]

Du hast Recht, das habe ich falsch verstanden! Der Hinweis für stdsql war für mich keine Erläutertung das es so auch auf der DB2 klappt(manche Sachen gehen ja auf der DB2 nicht oder nur anders), daher habe ich das nur schnell überflogen. Mein Fehler, Entschuldigung!

Die Schreibweise mit den || habe ich auch in der Referenz gelesen, jedoch akzeptiert RDi das nicht bei mir sondern wirft einen Fehler das dies so nicht korrekt sei.

[Fuerchau]

Wie Dieter schon schrieb, "||" ist von der CCSID zur Laufzeit abhängig und muss ggf. durch "!!" ersetzt werden. Wenn sich dann die Job-CCSID zur Laufzeit ändert funktioniert der SQL nicht mehr.

[LordCinimod]

Problem hat sich inzwischen erledigt
Habe vorhin noch einmal ein Versuch unternommen, dieser ging dann auch. Keine Ahnung was vorher das Problem war.....eventuell hat das neustarten der VM geholfen, kp!

Danke für die Erklärungen !

[holgerscherer]

manche Sachen gehen ja auf der DB2 nicht oder nur anders

Das ist immer eine Frage der relativen Betrachtungsweise. Auf der DB2 auf IBM i gehen die Sachen in der Regel richtig und elegant - andere Systeme strickeln auch rum. Da die aber weiter verbreitet sind, meint man, das wäre "normal" ;-)

-h

[B.Hauser]

Das ist immer eine Frage der relativen Betrachtungsweise. Auf der DB2 auf IBM i gehen die Sachen in der Regel richtig und elegant - andere Systeme strickeln auch rum. Da die aber weiter verbreitet sind, meint man, das wäre "normal" ;-)

-h

DB2 for i Syntax entspricht i.d.R. der SQL-Standard-Vorgaben, während andere Datenbanken-Hersteller eine eigene Version entwickelt haben und nicht einsehen warum das Rad doppelt erfunden werden sollte.
Aber auch auf der DB2 for i gibt es z.B. einige Funktionen doppelt (z.B. UCASE() und UPPER()). In diesem Fall hat IBM zu der "eigenen" Funktion UCASE noch die Standard Version hinzugefügt.
Wie Holger sagt, eigentlich muss es umgekehrt heißen, in anderen Datenbanken funktioniert es anders.

Birgitta

[BenderD]

... das sind ja nun doch überraschende Statements! Ausgerechnet Anhänger der Fraktion "Never use SQL Standard" reklamieren die beste Standard Konformität für DB2 auf der AS/400.
Wo ist denn bitte folgendes SQL konform:
- naming *sys
- commit *none
- Sperrverhalten eines Cursor a la RLA
- zwei Query engines, die sich unterschiedlich verhalten (Spezialistin: Madam SQE)
- commit level serializable ohne funktionierende Implementierung
um nur wenige Beispiel zu nennen.
Angemerkt sei noch, dass DB2 auf der AS/400 den anderen DB2 Varianten hinterher hinkt.

Am nächsten am Standard ist wohl PostgreSQL, DB2 dürfte knapp hinter Oracle irgendwo in der Mitte liegen, DB2 auf der AS/400 zusammen mit MS SQL ziemlich hinten, wertet man reale RPG SQL Applikationen, würden diese in Bezug auf ANSI SQL Konformität weit abgeschlagen auf dem letzten Platz landen.

Wer sich (wirklich) für das Thema interessiert, findet einen detaillierten Vergleich hier: http://troels.arvin.dk/db/rdbms/

Ich kann nur empfehlen sich mit dem Standard zu befassen! Man hat sich was dabei gedacht, dass SQL z.B. keine Ortung von Datenbank Objekten nach LIBL vorsieht!!!

D*B
PS: ansonsten bin ich hier bei Baldur: das, was man am besten kennnt hält man für normal. (Ausgerechnet das + Zeichen von MS SQL ist nicht Standard konform, ein grober Ausreißer bei MS SQL)

[Fuerchau]

Am Besten kann man das auch bei Microsoftprodukten, die auf SQL zugreifen verfolgen.
Der "SQL-Standard" schreibt für die casesensitive Namensverwendung Anführungszeichen vor, also "Dies ist mein Feld". Microsoft verwendet dagegen eckige Klammern: [Dies ist mein Feld].
Nimmt man nun das viel zitierte (fast kostenlose) Power BI kann man mit einer DB, die eckige Klammer nicht unterstützt, keine Daten bei casesensitiven Feldern abrufen.
Will man auf den nativen SQL, kommt man nur auf die Microsoft-Eigene MD-Abfragesprache.

Ebenso habe ich halt Schwierigkeiten, mit dem SQL-Verbindungsserver zur AS/400 zu arbeiten.
Hier muss man tatsächlich für alles eine View generieren da man nur eckige Klammern verwenden kann.

Beispiel SUBSTR:
SUBSTR(String, Pos, Länge) = DB2/400 (sehr alt)
SUBSTRING(String, Pos, Länge) = SQL-Standard (älter)
SUBSTRING(String from Pos for Länge) = SQL-Standard (neuer)

Dann gibts da noch Left() und Right(), die es für Oracle aber nicht gibt, hier wird substring() für Left und Substring() mit negativer Position für Right empfohlen.
Und so geht es lustig weiter.

Und somit steht man beim Import von Daten aus verschiedensten Quellen immer wieder vor dem Problem, was wird da nun für was benutzt.

Soviel halt zum Standard.