Regeln für die Feldgröße

[andreaspr@aon.at]

Das ist tatsächlich sehr interessant. Speziell da im Handbuch folgendes steht:
A numeric
argument is cast to a character string before evaluating the function.

Wenn man sich das mit dem Monitor anzeigen lässt sieht man, dass das Substring den Wert schon als CHAR übergeben bekommt.
Original:

Select substring(01234567, 5, 2) Into :v1
From sysibm/sysdummy1

Monitor:

SELECT Translate(Substring('01234567',5,2), *UNNAMED Table) 
FROM SYSIB00033/SYSDUMMY1 SYSDUMMY1_1

Sowohl in SQLRPGLE als auch mit JDBC.

lg Andreas

[Fuerchau]

Wie Dieter da immer so treffend sagt:

It's not a bug, it's a feature.

Wobei das ggf. mit irgendeinem nächsten PTF ja korrigiert werden könnte.
Ich würde mich da nicht drauf verlassen, da es ggf. auf anderen Datenbanken dann nicht so funktioniert.

Automatismen sind da immer kritisch.

Beispiel:
Bis V5R4 musst ich beim Aufruf einer von mir geschrieben SQL-Function die Parameter genau per manuellem cast übergeben.
Ab V6R1 scheint das Finden von Function/Proceduren "intelligenter" geworden zu sein, da auch bei nicht gecasteten Parametern hier SQL autcasts durchführt um doch mal die Function zu treffen.
Nicht ganz ungefährlich sowas, da ggf. nicht gewünschte Funktionen aufgerufen werden könnten bzw. die Typsicherheit nicht mehr so ganz gewährleistet ist.

[B.Hauser]

Das ist tatsächlich sehr interessant. Speziell da im Handbuch folgendes steht:
A numeric
argument is cast to a character string before evaluating the function.

Wenn man sich das mit dem Monitor anzeigen lässt sieht man, dass das Substring den Wert schon als CHAR übergeben bekommt.
Original:

Select substring(01234567, 5, 2) Into :v1
From sysibm/sysdummy1

Monitor:

SELECT Translate(Substring('01234567',5,2), *UNNAMED Table) 
FROM SYSIB00033/SYSDUMMY1 SYSDUMMY1_1

Sowohl in SQLRPGLE als auch mit JDBC.

lg Andreas

Das liegt daran, dass der Query Optimizer das SQL Statement zunächst analysiert, mit zusätzlichen Informationen erweitert und ggf. umschreibt. Erst anschließend beginnt die eigentliche Optimierung. Da ein Substring nur auf eine alphanumerische Angabe möglich ist, wird an dieser Stelle die erforderliche Konvertierung in den String integriert.

Birgitta

[B.Hauser]

Beispiel:
Bis V5R4 musst ich beim Aufruf einer von mir geschrieben SQL-Function die Parameter genau per manuellem cast übergeben.
Ab V6R1 scheint das Finden von Function/Proceduren "intelligenter" geworden zu sein, da auch bei nicht gecasteten Parametern hier SQL autcasts durchführt um doch mal die Function zu treffen.
Nicht ganz ungefährlich sowas, da ggf. nicht gewünschte Funktionen aufgerufen werden könnten bzw. die Typsicherheit nicht mehr so ganz gewährleistet ist.

Die Erleichterungen erfolgen nur für numerische und alphanumerische Konstanten oder Ausdrücke. Numerische Ausdrücke ohne Dezimal-Stellen werden als Integer-Wert interpretiert. Sofern keine Funktion mit einem Integer-Wert gefunden wird, wird geprüft ob eine Funktion mit einem anderen numerischen Parameter vorhanden ist. (Gepackt und dezont numerisch werden seit jeher als "gleich" interpretiert)

Ähnliches gilt für alphanumerische Parameter. Wird ein alphanumerischer Ausdruck übergeben wird geprüft, ob eine Funktion mit einem alphanumerischen Parameter mit variabler Länge vorhanden ist, sofern keine Funktion gefunden wird, wird geprüft ob eine Funktion mit einem alphanumerischen Parameter mit fixer Länge vorhanden ist. (Single und Double Byte Character Sets werden als "gleich" interpretiert und der übergebene Parameter-Wert ggf. konvertiert).

Birgitta

[andreaspr@aon.at]

Das liegt daran, dass der Query Optimizer das SQL Statement zunächst analysiert, mit zusätzlichen Informationen erweitert und ggf. umschreibt. Erst anschließend beginnt die eigentliche Optimierung. Da ein Substring nur auf eine alphanumerische Angabe möglich ist, wird an dieser Stelle die erforderliche Konvertierung in den String integriert.

Hallo Birgitta,
das hab ich eh geschrieben (siehe auch meinen Auszug aus dem Handbuch).
Interessant ist ja nur, dass scheinbar der sogenannte "CAST" einfach nur ein anfügen von Hochkommas ist. Speziell weil auch im nächsten Satz ein Verweis zur VARCHAR-Funktion gegeben ist um nähere Informationen über Konvertierung zu erfahren.
Also, wenn eben keine Konvertierung im Sinne von CAST oder (VAR)CHAR() gemacht wird, finde ich diese Beschreibung sehr irreführend, da sie nichts mit der Konvertierung für SUBSTR zu tun hat.

Hier der ganze auszug aus dem Handbuch:

Expression must be any built-in numeric or string data type. A numeric
argument is cast to a character string before evaluating the function. For more
information about converting numeric to a character string, see “VARCHAR”
on page 492.

lg Andreas

[Fuerchau]

Nun ja, laut SQL-Reference gilt dies auch für die Ausführung des SQL's.

Birgitta hat aber erklärt, dass vor der Ausführung noch der Optimizer zuschlägt.
Dieser muss sich ja nicht daran halten da er ja ggf. recodiert (optimiert).

Vielleicht gibts ja dazu mal irgendwann ein Redbook, der darauf und auch auf vieles andere hinweist .
immerhin gilt ja leider vieles aus der SQL-Reference nicht, wenn der Optimizer massiv in die SQL-Befehle eingreift und bei der Ausführungsschicht was anderes ankommt als ich eigentlich angegeben habe.
Ich hätte da gerne mal einen Hinweis irgendwo (z.B. Joblog bei Debug), welcher SQL nun tatsächlich zur Ausführung kommt ohne nun dieses kaum zu verstehende Analyselog aktivieren und ansehen zu müssen.

[andreaspr@aon.at]

Nun ja, laut SQL-Reference gilt dies auch für die Ausführung des SQL's.

Aso? Kann ja sein, dass ich mich irre, aber so wie ich das sehe, steht im Handbuch weder was davon dass es nur für Ausführung gilt noch dass von Optimizer irgendwas verändert werden kann.
Im Handbuch gibt es nämlich sehrwohl auch Hinweise auf den Optimizer, wenn dieser sich auf das Ergebnis auswirkt.

Ich sag ja nicht, dass es nicht so sein kann, wie Birgitta schrieb!

Ich meine lediglich, dass das System nicht das macht, was ich aus dem Handbuch erwartet hätte.