SQL zum verzweifeln

[DKSPROFI]

Moin *all,

ich habe hier eine merkwürdiges Problem.
Mein SQL

Exec SQL Declare C_ticket Cursor For Select *
From ANWDTASTM.PORTALP
Where POAEAR = '3'
AND POSTAT <> '*'
AND POUSDT = : Sysdat bzw. 05.02.2024 oder 2024-02-05
Exec SQL Open C_ticket ;

Funzt nicht mehr mit folgendem Fehler: SQL0303
Variable POUSDT nicht kompatibel oder Wert zu lang.
Egal, ob ich mit einem festen Wert oder mit der Variablen rangehe. Es kommt immer der selbe Fehler.

Ach so, das Feld POUSDT ist ein Datumswert.

Habt Ihr eine Idee?

[Andreas_Prouza]

Wenn POUSDT vom Type ein Datum ist, dann sollte die RPG Variable auch vom Typ ein Datum sein.
Oder du konvertierst um.

[camouflage]

Wenn es ein Datum ist, könntest Du auch mit CURRENT_DATE vergleichen.

[Fuerchau]

Hostvariablen sollten zum Datantyp passen.
Jetzt kommt es noch darauf an, wie du das Dateformat im RPG festgelegt hast:
- RPG-Header DateFmt() (o.ä.)
- SQL-Option datfmt
Die SQL-Ersatzvariablen (SQLnnnn) werden im Format von SQL-Option definiert und deine Hostvariable dann ggf. konvertiert.

[B.Hauser]

Wie ist denn SYSDAT überhaupt definiert? Datum oder alphanumerisch?
Wird beim Compilieren die Option DATFMT (oder in einem SET OPTION STATEMENT) auf ein Format mit einem 4-stelligen Jahr gesetzt.
Und was genau steht in der Variablen SYSDAT bevor der Cursor geöffnet wird.

Ansonsten ist SQL in der Lage jede gültige alphanumerische Darstellung eines Datums- und Zeit-Werts zu erkennen und richtig zu konvertieren, also YYYY-MM-DD, DD.MM.YYYY, MM/DD/YYYY, YYYYDDD (lfd.Tag im Jahr, YYYY-MM-DD-HH.MI.SS.MSMSMS, YYYYMMDDHHMISS.

[DKSPROFI]

Hallo Birgitta,

SYSDAT ist ein Datumsfeld, Datenart L.
die SET OPTION Geschichte ist DATFMT=*ISO
In der Variablen steht das Tagesdatum in der Form TT.MM.JJJJ oder JJJJ-MM-TT oder CURENT-DATE. Alles ausprobiert nichts hilft, immer noch SQL0303.

[Fuerchau]

Passiert der Fehler bereits beim Open oder erst beim Fetch?
Dann kann die Reihenfolge der Zielfelder in der DS abweichend sein vom Ergebnis des Select * und dann ein Umwandlungsfehler stattfinden..

[DKSPROFI]

Hallo Baldur,

der Fehler kommt erst beim FETCH.

[Robi]

Schau dir mal an, was in POUSDT in den Datensätzen steht.
Auch in Typ 'L' Feldern kann mal Schrott stehen.

[Fuerchau]

Dann prüfe mal in der erweiterten Umwandlungsliste (SQL-Auflösung), ggf. mit *LVL2 Umwandlung, wie die SQLnnnn Felder des Fetch definiert sind und ob diese denn zu den Zielfeldern passen.
Ich habe da schon mal das Problem, dass zur Compilezeit eine andere Tabelle verwendet wird als zur Laufzeit (LIBL, OVRDBF) und sich daher dann Verschiebungen ergeben.
Bei SQL gab es schon immer die Regel, die ich auch gerne verletze:
Verwende nie
- Select *
- Inser into Table Values()
- update set row
Auch wenn das alles schön praktisch ist, zur Laufzeit oder beim Wechsel zum Kundensystem gibts da schon mal Probleme, die bei klassischem RLA ja mit passendem CPF-Fehler abgewiesen werden.

[DKSPROFI]

Hallo Baldur,

das Feld ist 10 stellig mit Datumsformat *ISO definiert. Ich habe das Feld jetzt ausgelagert und Frage nach dem Fetch ab, aber immer noch der SQL-Fehler.

Meinst du ich soll das mal melden?

[Fuerchau]

Bitte überprüfe auch das SQLnnnn-Feld auf das Format, dass bei der Zuweisung angegeben wird.
Vielleicht betrifft es auch ein anderes Feld?
Wie gesagt, das kann man bei der *LVL2-Compileroption gut sehen.