-
 Zitat von BenderD
@Birgitta
SQL ist streng typisiert, alles und jedes wird auf Typverträglichkeit überprüft und der 1.1.01 passt nun mal nicht in eine Feld mit einem Typ, der einen Wertebereich vom 1.1.1940 bis 31.12.2039 hat.
Dieter Bender
@ Dieter,
dann erkläre mir doch mal bitte, warum in folgendem Programm ein Satz ordnungsgemäss in eine Datei geschrieben und angezeigt wird, obwohl das verwendete SQL-Format nur ein 2-stelliges Jahr zulässt.
PHP-Code:
D MyRPGDate S D DatFmt(*ISO)
C/EXEC SQL Set Option DatFmt = *DMY, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Und jetzt erkläre mir, warum im folgenden Beispiel ein Satz in die Datei geschrieben wird, aber beim SELECT INTO ein Abbruch erfolgt mit RNQ0114 - Die Jahresangabe eines Datums- oder Zeitmarkenwerts liegt nicht innerhalb des korrekten Bereichs (C G D F).
(Der einzige Unterschied ist, dass ich die Datums-Formate von SQL und RPG vertauscht habe)
PHP-Code:
D MyRPGDate S D DatFmt(*DMY)
C/EXEC SQL Set Option DatFmt = *ISO, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Birgitta
-
Der Unterschied liegt darin, dass beim Insert eine Konstante verwendet wird und diese ist korrekt, da das Datum der DB ja alles aufnehmen kann.
Probleme gibt es aber beim KONVERTIEREN DB <=> Programm !!!
-
A ja... sowas habe ich gerade auch noch mal in der RPG-Hilfe gefunden! Macht sinn, dass er dann nen Fehler zeigt!
Aber gut... schönen Dank noch mal für die Hilfe!!
Viele Grüße,
Tobias
-
 Zitat von Fuerchau
Der Unterschied liegt darin, dass beim Insert eine Konstante verwendet wird und diese ist korrekt, da das Datum der DB ja alles aufnehmen kann.
Probleme gibt es aber beim KONVERTIEREN DB <=> Programm !!!
Ok, es gibt einen Abbruch, wenn man eine Host-Variable mit anderem Format verwendet, aber die Fehlermeldung ist RNX0114, also eindeutig ein RPG-Fehler! Ein SQL-Fehler würde einen negativen SQLCOD zurückbringen!
Birgitta
-
@Birgitta,
das ist doch gerade der Witz an einer strengen Typprüfung - es wird frühestmöglich geprüft: alles was beim Compile geht, wird dort vernagelt und möglichst wenig zur Runtime.
Einen SQL Runtime Fehler kannst Du bei dieser Angelegenheit nur mit dynamic SQL hinkriegen.
Dieter
 Zitat von B.Hauser
Ok, es gibt einen Abbruch, wenn man eine Host-Variable mit anderem Format verwendet, aber die Fehlermeldung ist RNX0114, also eindeutig ein RPG-Fehler! Ein SQL-Fehler würde einen negativen SQLCOD zurückbringen!
Birgitta
-
Ausserdem sieh dir die RPG-Umwandlungs-Liste an !
Die SQL's arbeiten NIE mit den angegebenen RPG-Feldern sondern es werden neue RPG-Felder generiert, die natürlich passen, und dann per RPG-Move übertragen (konvertiert). Daher eben ein RPG-Fehler und kein SQL-Fehler.
-
@Birgitta
1. Die Felder in der Datenbank haben ein internes Format, das beim Übergang zu Hostvariablen konvertiert wird.
2. Die SQL Anweisung SET OPTION (oder CRTSQLXXX äquivalent) ist eine Compiletime Anweisung für embedded SQL, bei interaktivem SQL und wirkt auf die Konvertierung zwischen alfa und internem Datumsformat und hat Auswirkungen auf Gültigkeitsbereiche (sliding Window für 2 stellige Jahresangaben).
3. RPG Variablen haben ein Datumsformat, das das Regelwerk steuert wie aus SQL auf (in Wirklichkeit Alfa) Datumsfelder gemappt wird.
4. Literale haben keine Typbindung und RPG versucht das irgendwie hinzukriegen. Für Eingabewerte sind die immer interpretierbaren Formate (Trennzeichen, Reihenfolge, Länge) *ISO *EURO *AMI und *JIS immer gültig.
 Zitat von B.Hauser
@ Dieter,
dann erkläre mir doch mal bitte, warum in folgendem Programm ein Satz ordnungsgemäss in eine Datei geschrieben und angezeigt wird, obwohl das verwendete SQL-Format nur ein 2-stelliges Jahr zulässt.
PHP-Code:
D MyRPGDate S D DatFmt(*ISO)
C/EXEC SQL Set Option DatFmt = *DMY, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Birgitta
Der Insert klappt, da *ISO Literale immer interpretierbar sind (siehe SQL Reference beim set option), Das auslesen klappt, da das interne Format auf das (passende) Format der Host Variablen gemapt wird.
 Zitat von B.Hauser
Und jetzt erkläre mir, warum im folgenden Beispiel ein Satz in die Datei geschrieben wird, aber beim SELECT INTO ein Abbruch erfolgt mit RNQ0114 - Die Jahresangabe eines Datums- oder Zeitmarkenwerts liegt nicht innerhalb des korrekten Bereichs (C G D F).
(Der einzige Unterschied ist, dass ich die Datums-Formate von SQL und RPG vertauscht habe)
PHP-Code:
D MyRPGDate S D DatFmt(*DMY)
C/EXEC SQL Set Option DatFmt = *ISO, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Birgitta
Der Insert klappt wieder, weil *ISO Literal, die Konvertierung des internen SQL Formats in die Hostvariable scheitert am zu kleinen Wertebereich der *DMY RPG Variable.
Anmerkung: der SET OPTION Befehl ist in den beiden Beispielen dermatologisch geprüft (den kann man sich bedenkenlos in die Haare schmieren)
mfg
Dieter
Similar Threads
-
By robertki in forum NEWSboard Programmierung
Antworten: 25
Letzter Beitrag: 19-01-07, 09:42
-
By timeless in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 11-01-07, 13:04
-
By Stoeberl in forum NEWSboard Programmierung
Antworten: 8
Letzter Beitrag: 10-01-07, 11:58
-
By jth in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 21-12-06, 12:13
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks