SQL zum verzweifeln

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

[DKSPROFI]

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.

Bingo, das wars. Ich war ja sowas von Blind. Die Datei gibt es in mehreren Bilbliotheken, ich habe lediglich meine Liste ncht angepasst. Vielen Dank, allen

[Fuerchau]

Siehst du, auch ich war heute in meinem Bereich das Problem vor dem Bildschirm.
Warum soll es anderen nicht auch mal so gehen.

Noch 4 Wochen, dann wird das wohl mein Lieblingssong;-):
https://www.youtube.com/watch?v=4ay8C8dAqEg