[NEWSboard IBMi Forum]

Thema: SQL Datum

  1. #1
    Registriert seit
    Oct 2015
    Beiträge
    109

    SQL Datum

    Hallo zusammen,

    ich habe 3 Felder (Jahr, Monat, Tag) und möchte die als ein Datumsfeld im SQL ausgeben.
    Versucht habe ich: date(digits(JAHR)!!'-'!!digits(MONAT)!!'-'!!digits(TAG) as Datum
    Dabei erhalte ich dann zB 24.12.16
    Ich hätte jedoch gern 24.12.2016
    Zudem kann SQL auf der DB2 angeblich bis 31.12.9999, gebe ich das an erhalte ich jedoch
    nur "+++++++++" als Ergebnis.

    Könnt ihr mir helfen?

  2. #2
    Registriert seit
    Nov 2003
    Beiträge
    2.304
    STRSQL > F13=Service > 1. Sitzungsattribute ändern > Datumsformat . . . *EUR

  3. #3
    Registriert seit
    Oct 2015
    Beiträge
    109
    Vielen Dank!
    Jetzt übersetzt er auch die 9999

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das Datumformat ist besonders bei embedded SQL wichtig da auch hier Laufzeitprüfungen stattfinden.
    Dabei wird auch noch zwischen RPG-Datum und SQL-Datum unterschieden!
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    SQL interessiert das Datums-Format überhaupt nicht und SQL kennt auch kein Datums-Format. SQL arbeitet immer mit dem Binär-Wert/laufenden Zähler (der scaliger no).
    Ein Datums-Format wird nur benötigt, um den binären-Datums-Wert lesbar zu machen.
    Welches Format dabei verwendet wird, hängt davon ab, welches im aktuellen Job bzw. der aktuellen Verbindung gerade verwendet wird.
    Liegt ein Datum außerhalb des anzeigbaren bereichts, wird ++++++ ausgegeben.
    Berechnungen, Inserts und Updates werden jedoch korrekt , d.h. mit dem richtigen Datum ausgeführt.

    In RPG ist das etwas anders, da RPG die scaliger no immer abh. vom Format der Variablen in eine alphanumrische Darstellung konvertiert und erst unmittelbar vor dem Zurückschreiben wieder in die Scaliger No konvertiert.
    Deshalb kann es in RPG vorkommen, das es beim Übertragen von einem Datums-Wert in ein anders Datums-Feld trotz des gleichen Daten-Typs aufgrund von unterschiedlichen Datums-Formaten zu Feldüberläufen kommen kann.

    Bei embedded SQL ist es so, dass für jede Host-Variable eine zusätzliche Variable generiert wird. Bei der Definition von Datums-Feldern wird nicht das Datums-Format der Host-Variablen, sondern das Datums-Format, das bei der Compilierung angegeben wurde verwendet. Und der Default-Wert für das Datums-Format ist *JOB.

    Der Abbruch erfolgt dann, wenn z.B. eine RPG-Host-Variable mit Datums-Format *ISO, die mit *LOVAL initialiert ist, in die SQL-Variable (mit einem Datums-Format mit nur 2-stelligem Jahr) übertragen wird ... dann macht RPG (und nicht SQL) den Abflug.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Hier liegst du leider falsch.
    Die DB interessiert sich tatsächich nicht dafür, SQL sehr wohl.
    Durch OPTION DATFMT wird für den Precompiler festgelegt, wie die SQL-Variablen eines Datums generiert werden denn für jede Hostvariable wird (dummerweise) eine SQLxxxx-Variable definiert.
    SQL (hier der Precompiler) generiert dann das Datumformat explizit für jede Variable.

    Die H-Bestimmung ist für die RPG-Variablen zuständig, die ich selber ohne ein Datumformat definiere.

    Wenn ich dann also ein *DMY-Format für SQL festlege gibts zur Laufzeit von SQL einen negativen SQL-Code (oder NULL-Anzeiger -2) da ggf. der DB-Inhalt nicht in die SQL-Variable übertragen werden kann.
    Eine RPG-Laufzeitfehler gibt es bei der Übertragung meines Datums von *ISO in die SQL-generierten Variablen.
    Habe ich für SQL *ISO/*EUR festgelegt und für RPG dann *DMY gibt es einen RPG-Laufzeitfehler bei der Übertragung aus SQL-Variable in Hostvariable.

    Noch mal zur Begrifflichkeit:
    SQL ist die Sprache der DB umd muss sehr wohl das verwendete Datumformat kennen.
    Selbst bei ODBC/JDBC muss ich das Datumformat korrekt definieren da SQL sonst nicht damit umgehen kann.

    Wie die DB letztlich intern ein Datum speichert ist in der sache vollkommen irrelevant.

    Die "+++++"-Ausgabe ist eine Spezialität des STRSQL und hat mit embedded SQL nichts zu tun.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Die DB interessiert sich tatsächich nicht dafür, SQL sehr wohl.
    Eine RPG-Laufzeitfehler gibt es bei der Übertragung meines Datums von *ISO in die SQL-generierten Variablen.
    Merkst Du eigentlich, dass Du Dir wiedersprichst!
    RPG crasht und nicht SQL! Die zusätlichen Host-Variablen sind RPG-Variablen, die lediglich vom SQLPreCompiler in den Source Code eingebunden werden.
    RPG konvertiert die scaliger no immer in ein lesbares Format abh. von Angaben in den D- oder H-Bestimmungen. Innerhalb des Programms wird die alphanumerische Variablen hin- und hergeschoben und erst unmittelbar vor dem Zurückladen wieder in die scaliger no konvertiert. Der Überlauf/Crash passiert innerhalb von RPG wenn die Datums-Formate nicht zusammen passen.
    Das passiert aber auch, wenn echte RPG-Datums-Variablen mit nicht zusammenpassenden Formaten umgeladen werden.

    SQL ist die Sprache der DB umd muss sehr wohl das verwendete Datumformat kennen.
    SQL kann die alphanumerische Darstellung eines Datums im Format YYYY-MM-DD (ISO), DD.MM.YYYY (EUR), MM/DD/YYYY (USA) erkennen und korrekt verarbeiten. SQL kann ebenfalls ein Datum aus einer gültigen alphanumerischenb Zeitmarken-Darstelllung YYYY-MM-DD-HH.MI.SS.MSMSMS (ISO), YYYY-MM-DD HH:MM:SS.MSMSMS (ANSI), YYYYMMDDHHMMSS herausbrechen. Beides ist unabhängig von dem Format, das im Job oder der aktuellen Verbindung gerade verwendet wird.
    Diese Darstellung wird in die entsprechende scaliger no konvertiert und dann verarbeitet.
    Bei Datums-Angaben mit 2-stelligem Jahr, muss das Format angegeben bzw. korrekt sein, da SQL weder die Position des Jahres noch aufgrund der Trennzeichen das eigentliche Format ermitteln kann!

    Warum gibt es wohl in SQL DDL keinen Editier-Code für ein Datum wie in DDS?
    ... weil es nicht interessiert!

    Wenn das Datum nicht angezeigt werden kann, ist das ein Problem der Verbindung bzw deren Definition und kein Problem von SQL.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Warum soll ich mich darüber streiten?
    Ich kann nur sehen, was im Compiler-Listing passiert.
    Hier werden QSQ-Routinen (also SQL) aufgerufen die mit RPG-Variablen umgehen.
    Klar prüft die RPG-Runtime, dass in der Datumsvariablen die Zeichendarstellung des Datumformates korrekt ist. Zwischen SQL (also den QSQ-Calls) und RPG werden eben nur Zeichenvariablen vom Typ Datum ausgetauscht.
    Enthält die DB beim Lesen eines Datums z.B. den1.1.0001 bekomme ich bei NULL-Anzeiger das Datum erst gar nicht übergeben. Dies liegt darin begründet, dass in der internen SQLDA eben das Datumformat für den Austausch ereits festgelegt ist.
    SQL und nicht die DB ist für das hin- und herkonvertieren zwischen Programm und DB verantwortlich.
    Wenn mir also der SQL-Precompiler nun mal RPG-variablen vom Typ DD.MM.YY erstellt, kann die RPG-Runtime nun mal nichts anderes zulassen.
    Was die Datenbank (das sind dann QDB-Programme) damit macht ist mir letztlich egal.
    Die interne "scaliger" spielt in diesem Umfeld keine Rolle.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. SQL Datum konvertieren
    By weidenhammer in forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 07-05-15, 12:37
  2. Datum in SQL Funktion prüfen
    By malzusrex in forum NEWSboard Programmierung
    Antworten: 6
    Letzter Beitrag: 07-11-14, 09:01
  3. Datum die xte + 1 SQL V5R4
    By KingofKning in forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 25-07-14, 16:45
  4. Datum berechnen mit CL
    By j.k. in forum NEWSboard Programmierung
    Antworten: 12
    Letzter Beitrag: 15-11-10, 17:31
  5. Datum + 10 Tage in RPG
    By HoScHiE in forum IBM i Hauptforum
    Antworten: 11
    Letzter Beitrag: 06-08-01, 15:47

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •