Variable als Selektionsbegriff im "in" bei embedded SQL

[Fuerchau]

Nun ja, entweder dynamisches SQL oder statisches.
Beim statischen SQL musst du eben 1000 Variablen aufführen.
Aber es gibt da noch einen kleinen Trick (den ich auch gerne verwende):

Nimm deine obige InSelekt-Variable und baue die Werte immer mit einen Trennzeichen zusammen (auch am Ende!).
"Wert1; Wert2; .....; WertN; "

Nun vergleiche:

where POSSTR(: InSelect, char(Feld) concat '; ' ) > 0

Bei numerischen klappt das ja ganz gut. Bei Zeichenketten muss man sich da schon ein Trennzeichen einfallenlassen, dass so nicht vorkommt. Hier bieten sich Hexwerte ganz gut an, da dies sowohl von ILERPG als auch SQL unterstützt wird, z.B. X'01'.

[Robi]

Wenn die Werte noch nicht alle feststehen und es sehr viele werden können ...
Stehen die evtl. in einer Datei ?

select ... from ... where feld in (select distinct Feld2 from Datei where ... )

Robi

[Fuerchau]

Aus Performancegründen kann es besser sein "where exists (select * from filex where outerfile.field = filex.key)". Hier wird von SQL nur ein Zugriff (bei Index) durchgeführt. Beim obigen "in (select distinct ...)" wird dies ggf. für jeden Satz wiederholt!

[dschroeder]

Vielen Dank an alle. Ich bin mir bewusst, dass es eine ganze Reihe von Möglichkeiten gibt, das Problem anders zu lösen: Dynamisches SQL, Schlüssel in eine Datei schreiben, ...

Mein Favorit war halt statisches SQL. Deshalb habe ich gefragt.
@Baldur: Der Trick ist nicht schlecht, aber ich befürchte da doch Performanceeinbußen, da das SQL ja erstmal eine char-Funktion für jeden Satz der Datei ausführen müsste.

Aber ihr alle habt mir sehr weitergeholfen, weil ich jetzt weiß, dass es über meinen favorisierten Weg nicht geht. Ich werde jetzt irgendeinen anderen Weg nehmen.

Vielen Dank.

[Fuerchau]

Dateizugriffe kosten Performance!
Ein bisschen Rechnerei ist da eher unkritisch. Ich denke pro Satzzugriff kannst du durchaus mehrere Millionen Rechenoperationen durchführen.
Die Performance ist weniger das CHAR und der POSSTR sondern dass deine Selektion keinen Index verwenden kann.
Was du wohl machen kannst ist:
- Schreibe die In-Werte in eine neue Tabelle, ggf. Job-Nr. als Hilfskey
- Verknüpfe deinen SQL mit "inner join ", aber ggf. von der neuen Tabelle auf die Haupttabelle
Man sollte immer einen
"Select ... from KleinsteTabelle inner/left join GrößereTabelle on ..." versuchen und für die Beziehungen Indizes anlegen.

[dschroeder]

Ich bin bereits dabei, eine Hilfsdatei anzulegen.

Aber nochmal zu deinem Posstr. Ich meinte nicht die Perfomance wegen der Berechnung, sondern die Problematik, dass wegen des fehlenden Index jeder Satz der Datei mit Posstr überprüft werden muss.

Danke nochmal.
Dieter