Regeln für die Feldgröße

[Robi]

Alle Zahlen ohne Nachkomma werden zu Integer (in ILERPG eben 10I => +/- 2^31-1).
Mit Nachkomma oder wenn der Wert zu groß ist werden nach Möglickeit Dezimalfelder (bis max 31/63 Stellen) genommen, wenn das nich passt, dann double.

ok, also meistens 10 Stellen
Test : select digits(5) from datei --> bbbbbbbbb5
Passt

2. test select digits(5,2) from datei
erwartung: b (29) und 52
ist: 52
3. test: select digits(feld) from Datei
mit Feld = Num 5,2 erwartet: bbbbbbb ..152
ist: 000152 ( hier 0 nicht blank)

Wo sind die 'regulären' 31 Stellen die ich aus deiner antwort erwartet hätte?

Danke

@Pikachu
bis ich den Wälzer auswendig kann, bin ich in Rente.
Aber ich kann ja mal anfangen

Robi

[Fuerchau]

Also bzgl. der DIGITS-Funktion hast du ggf. ein Anzeigeproblem.
Die Funktion sollte immer mit Vornullen ausgeben. Warum das bei dir nicht funktioniert kann ich nicht sagen.
Versuch mal einfach
char(digits(12345))
Hierbei ist die Anzeige/Ausgabe erst mal außen vor.

Im Handbuch steht nichts anderes als ich hier gesagt habe.
Die 31 Stellen werden nur verwendet, wenn die Konstante auch 31 Ziffern (incl. Nachkomma) hat (ich schrieb ja bis max), also z.B.
1234567890123456789012345678901
123456789012345678901,2345678901

Ansonsten versucht SQL den kleinsten gemeinsamen Nenner zu ermitteln (Stichwort Union).

Auch bei Berechungen F1 * F2 wird das Ergebnisfeld dann größer, da gibts auch Regeln.

[Robi]

ok,
Größenregel für Digits:

Ganzzahlen von / bis +/- 2^31-1 : immer 10 Stellig
Dezimalzahlen: so viele Stellen wie sie haben.
Rechenergebnisse: immer noch größer --> Testen

Das mit dem Char ist klar, würde hier auch gehen. Aber da hier, wie überall 'mit den Augen geklaut' wird fällt der nächste, der das Datum als ttmmjjj verarbeitet auf den Bauch

Danke
Robi

[BenderD]

... das Problem sind Literale, die haben keinen expliziten Typ, da muss sich SQL einen auswürfeln (da mag es ein Regelwerk geben, aber warum soll man sich das Leben schwer machen...)

bei mir jedenfalls:
select 'a' || digits(20121016) || 'e'
from sysibm.sysdummy1

String Expression
a0020121016e
******** End of data ********

select 'a' || digits(dec(20121016, 8, 0)) || 'e'
from sysibm.sysdummy1

String Expression
a20121016e
******** End of data ********

entweder ist dein Feld dec(10, 0) oder das DB2/400 hat einen Schuss.

D*B

[Robi]

Moin,

beide Bsp bei mir genau so !
Auch das erste mit der 0 !

aber

Ich hatte eine Num. Variable mit jjjmmtt und wollte das Jahr bzw den Monat extrahieren.

also aus numerisch alpa machen
digits(&GRJJMT)

daraus (z.B. den Monat) extrahiereneinen
subsstr(digits(&GRJJMT), 5, 2)

und das wieder 2 Stellig numerisch machen um es mit dem Periodenmonat zu vergleichen

dec(subsstr(digits(&GRJJMT), 5, 2), 2, 0)

Nur das das Ergebniss meistens 12 war, da
digits(&GRJJMT) = digits(20121016) = 'bb20121016)


Nun weis ich, es geht auch ein
substr(&GRJJMT, 5, 2) = substr(20121016, 5, 2)

da SQL gar nicht weis, das 20121016 numerisch ist

Robi

[Fuerchau]

Aber hier hast du bzgl. des "abkupferns" das selbe Problem.
Hier wird ein Autocast mittels CHAR durchgeführt.
Übergibst du also mal TTMMJJJJ fehlt dir wieder die Vornull.

Und SQL stellt natürlich fest, dass du keinen String übergeben hast sondern einen numerischen Wert.
Dieser wird dann erst in Integer gewandelt und dann mittles cast in Char.

Wenn du es genau machen willst müsstest du auch einen String übergeben:

SETVAR((GRJJMT ('''' *cat &GRJJMT *cat '''')))

[Robi]

nun bin ich komplett verwirrt!

ein
select substr(01234567, 5, 2) from Sysibm.sysdummy1

ergibt ein 45 also zählt die 0 mit.

Also weiß SQL entweder doch nicht, das das ein Num Wert ist, oder der 'interne cast in char' funktioniert anders als der externe.

Robi

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

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

[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

[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