BenderD
25-05-23, 19:04
Aber Dieter, noch nichts von Replace gehört?
Bei der Stringaufbereitung dann jedes Feld noch per %replace oder noch besser;-) per SQL Replace anzupassen.
GTT werden im Programm deklariert, der Create Table wird automatisch gemacht.
Beim alten Standard ist das halt mit den statischen SQL's das Problem, dass du zur Compile-Zeit eine Tabelle benötigst, die du dann zur Laufzeit ggf. nach QTEMP duplizierst und per OVRDBF umbiegst.
GTT macht den Declare, so dass alle statischen SQL's damit zur Compilezeit umgesetzt werden können. Und die QTEMP wird dann automatisch verwaltet.
Du hast Recht, es ist kein Unterschied, nur der Aufwand ist erheblich geringer.
Ein DS-Array kann nur per Returns Table verwendet werden und ist überhaupt nicht elegant.
... von replace stand da nix - zum Glück hat ja DB2/400 (ich weiß, das "B" muß "b" heißen und "/400" heißt jetzt " for i" und "UDB" ist auch out) einen gewissen Grundschutz gegen injection...
D*B
Bei der Stringaufbereitung dann jedes Feld noch per %replace oder noch besser;-) per SQL Replace anzupassen.
GTT werden im Programm deklariert, der Create Table wird automatisch gemacht.
Beim alten Standard ist das halt mit den statischen SQL's das Problem, dass du zur Compile-Zeit eine Tabelle benötigst, die du dann zur Laufzeit ggf. nach QTEMP duplizierst und per OVRDBF umbiegst.
GTT macht den Declare, so dass alle statischen SQL's damit zur Compilezeit umgesetzt werden können. Und die QTEMP wird dann automatisch verwaltet.
Du hast Recht, es ist kein Unterschied, nur der Aufwand ist erheblich geringer.
Ein DS-Array kann nur per Returns Table verwendet werden und ist überhaupt nicht elegant.
... von replace stand da nix - zum Glück hat ja DB2/400 (ich weiß, das "B" muß "b" heißen und "/400" heißt jetzt " for i" und "UDB" ist auch out) einen gewissen Grundschutz gegen injection...
D*B