SQL? Wieso "Datenumsetzung bei Fetch erforderlich"

[JonnyRico]

Hi,

mal eine kurze Frage. Ich hole aus einer PF mit SQL ein paar Daten

D $FLD            S              7S 0 
.
.
.
C+ Fetch Next From MyCur Into :$FLD :$AnzFLD
.
. 

Das Feld ist in der PF definitiv 7 Zoned 0. Wenn ich jetzt den Cursor öffne und die Daten per Fetch holen will. Bekomme ich im Joblog die Meldung. Datenumsetzung erforderlich Ursache 2. Die Meldung sagt mir also das die nummerischen Werte nicht übereinstimmen. Kann mir jemand vielleicht sagen wie SQL denn bitte darauf kommt?? Bin über jeden Tip dankbar.

Gruß

Sascha

[Fuerchau]

Das liegt leider an dem RPG-Compiler.
Der hält Zoned nicht immer für Optimal und verwendet für Single-Fields dann halt gepackt.
Stelle das Feld in eine DS, dann darf der Compiler den Typ nicht ändern.

[JonnyRico]

Hey super. Danke Baldur. Was fällt den Compiler nur ein an meinen Felder rum zu drehen

Gruß

Sascha

[Fuerchau]

Tja, auch der Compiler kann optimieren.
Irgendwo kann man auch ein *NOOPTIMIZE angeben, aber ich weiß nicht mehr wo.
Schließlich weiß der Compiler ja, welche Variablen schneller sind.
Allerdings bei DSP/PRT-Filefeldern sind diese IMMER zoned ausser man definiert diese Felder wiederum eigenständig als gepackt in (externen) DS'n.

[BenderD]

Hallo,

hier handelt es sich wohl weniger um optimieren, als um Altersstarrsinn, das Ding ist an mehreren Stellen auf dem Stand von ca. 1870 stehen geblieben:
- kann variablen Scope von Variablen nicht korrekt einordnen
- kann input Variablen von Prozeduren und Programmen nicht korrekt verarbeiten
- kann etliche Datentypen nur ungefähr abbilden
- verträgt nicht alle Variablennamen
Da sind etliche Workarounds angebracht, um diesem auszuweichen, einer davon ist der in diesem Thread erwähnte, nämlich Variablen in einer (globalen) Datenstruktur deklarieren.

mfg

Dieter Bender

Tja, auch der Compiler kann optimieren.
Irgendwo kann man auch ein *NOOPTIMIZE angeben, aber ich weiß nicht mehr wo.
Schließlich weiß der Compiler ja, welche Variablen schneller sind.
Allerdings bei DSP/PRT-Filefeldern sind diese IMMER zoned ausser man definiert diese Felder wiederum eigenständig als gepackt in (externen) DS'n.

[JonnyRico]

Moin,

eine Frage hätte ich da noch. Bei einem Feld klappt es einfach nicht. Ich habe es in eine DS gestellt und wird vom Compiler auch nicht geändert. Es ist vom Typ 14S 3 . Ich habe im SQL ein berechnetes Feld, dass ich mit DEC(Meine Berechnung, 14, 3) doch eigentlich richtig "caste" oder? Leider bekomme ich auch hier einen Fehler 2 beim Fetch
Habt ihr vielleicht noch einen Tip?

Gruß

Sascha

[Fuerchau]

Tja, Sascha, "S" = Zoned, dec(...) = Packed, alles klar ?

[JonnyRico]

Tja, Sascha, "S" = Zoned, dec(...) = Packed, alles klar ?

Okay danke,
jetzt ist's klar

Gruß

Sascha