rpg sql, where mit "in" und hostvariable

[karin]

hallo allerseits,

heute hatte ich folgendes Problem und frage mich, warum das so nicht klappt...

aufgabe: es soll im rpg mit einem SQL-Statement geprüft werden, ob ein wert in einer liste von werten vorkommt.

die Idee war, das SQL so zu schreiben:

dcl-s found ind inz;
exec SQL select '1' into :found from Datei where dateifeld in('ABC', 'DEF', 'YXZ');
das würde ja noch funktionieren, jetzt aber die variante, die leider nicht klappt:


dcl-s found ind inz;
dcl-s vergleich char(50);
vergleich = ' (''ABC'', ''DEF'', ''YXZ'') ';
exec SQL select '1' into :found from Datei where dateifeld in :vergleich ;

da findet das SQL nix, sqlcode = 100

kann mir jemand sagen, ob man so eine where-Bedingung mit in und hostvariable überhaupt machen "darf"?

ich habe das jetzt mit dyna-SQL gelöst, klappt 1a, aber mich würde interessieren, was an der variante oben falsch gemacht ist.

danke :-)

[B.Hauser]

Das geht so nicht.
Du musst für jedes Element eine eigene Host-Variable definieren.

Die andere Alternative wäre dynamisches SQL zu verwenden

Birgitta

[karin]

hallo Birgitta,
habe es befürchtet, aber gut zu wissen! mit dyna-SQL funktioniert es ja prima..
danke für deinen hinweis!
lg Karin

[Fuerchau]

Wenn man die Strings entsprechend zusammenschustert kann man das auch per POSSTR() in einem Rutsch erledigen:

Posstr("!W1! !W2!", "!W1!") > 0

vergleich = ' ''ABC'' ''DEF'' ''YXZ'' ';
exec SQL select '1' into :found from Datei where posstr(:vergleich, '"' concat dateifeld concat '"' > 0;

[karin]

cool, klappt, ist gespeichert, so einfach..., danke!!!

[B.Hauser]

Die Lösung von Balur geht allerdings auf die Performance! Mit POSSTR kann der Optimizer keinen Index verwenden, d.h. es werden alle Datensätze verarbeitet, was bei großen Tabellen laaaaaaaaaaaange dauern kann.
Bei der Version mit IN kann der Optimizer einen Index verwenden und somit gezielt zugreifen.

Birgitta

[Fuerchau]

Das ist von Fall zu Fall unterschiedlich. Ob es auf die Performance geht entscheiden auch weitere Randbedingungen.
Wobei ich bisher noch nie gesehen habe, dass eine IN-Klausel mit Konstanten einen Index bevorzugt hätte.