View Full Version : substr bei SQL
oopsy-dear
08-11-05, 09:43
Kann es sein. daß ab Rel. V5R3 beim interaktiven SQL (strsql) substr mit numerischen Feldern möglich ist? Wir haben ein V5R2 und eine V5R3- Umgebung und bei V5R3 funktoiniert ein sql-update auf eine Datenbank-Datei mit eine Ausahl mittels substr auf ein Datumsfeld, bei V5R2-Umgebung nicht. Oder kann die Ursache eine andere sein??
Kann sein, dass bei V5R3 einige automatische CAST's zusätzlich vorhanden sind.
Allerdings sollte man sich auf sowas nie verlassen, sondern seine CAST immer salber spezifizieren.
In diesem Fall also "SUBSTR(CHAR(MYDATE), pos, len)", wobei solche Sachen mit Vorsicht zu geniessen sind, da gerade Datumskonvertierungen stark von der Job-Umgebung bzw. SQL-Einstellung abhängig sind.
Siehe beim STRSQL und F13->1 nach dem aktuellen Datumsformat !
PS:
Dafür gibts ja die Extract-Funktionen YEAR(MYDATE), MONTH(MYDATE) und DAY(MYDATE) um diesem Problem aus dem Weg zu gehen !!!
Schein wohl so zu sein. ich habe es gerade auf unserem system mit v5.3 probiert und es funzt.
auf einem kundensystem mit 5.2 geht es net.
muss wohl neu sein unter 5.3
gruß ronald
Vielleicht steht ja beim STRSQL in V5R3 nur der Default für das Datumformat jetzt auf *ISO ?
PS:
Ich habe ja auch V5R3 im Zugriff, aber bei mir wird beim SUBSTR gemeldet, dass eine Zeichenkette/Feld erforderlich ist !!!
Bei uns geht's unter V5R3 nicht ohne CHAR() allerdings auch nicht mit *ISO
hat bei mir eigentlich nix mit einem datums feld zu tun. ich habe willkürlich mal ein NUM-feld (7, 0) genommen.
das problem ist nur, das er die zahl wohl intern in ein charfeld linksbündig ohne vornullen macht, so das ein umweg über digits wohl doch besser ist
ronald
am ende ist es villeleicht ja nur ein bug (http://www.swr3.de/info/magazin/kaefer/) ??
Ich sagte ja, mit automatischen CAST's sollte man vorsichtig umgehen.
Aber es stimmt, numerische Felder werden automatisch gecastet.
Da kann ich nur sagen: Dies wird zusätzliche Probleme aufwerfen, da mitumter das Ergebnis nicht das gewünschte sein wird. Ganz davon abgesehen, dass solche "Fehler" mitunter erst Tage/Wochen/Monate später festgestellt werden.
Mit anderen Worten:
"I's not a feature, it's a bug !" ;)
hat bei mir eigentlich nix mit einem datums feld zu tun.
Also bei einem Zahlenfeld funzt es bei mir auch aber mit Datum ohne CHAR keine Chance
oopsy-dear
08-11-05, 10:33
Bei uns geht's unter V5R3 nicht ohne CHAR() allerdings auch nicht mit *ISO
Auf unserer 520 geht´s mit *DMY und mit *ISO. Das Feld steht im dspffd als packed (8,0). Auf der Kundenmaschine V5R2 geht´s weder mit *DMY oder *ISO. Seltsam. Ich werde mich mal an den IBM Softwareservice wenden. Ihr hört von mir!
Auf unserer 520 geht´s mit *DMY und mit *ISO. Das Feld steht im dspffd als packed (8,0). Auf der Kundenmaschine V5R2 geht´s weder mit *DMY oder *ISO. Seltsam. Ich werde mich mal an den IBM Softwareservice wenden. Ihr hört von mir!
Packed ist ja auch nicht Date.