DB2 und Concat von Strings?

[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.