Variable als Selektionsbegriff im "in" bei embedded SQL

[dschroeder]

Hallo,
ich möchte per statischem embedded SQL eine where - Selektion mittels "in" und einer Variable erzeugen. Das funktioniert nicht.

Beispiel:

inSelekt = '1000000160994, 1000000323058, 1000000014723';


exec sql select count(*) into :i from kunde
where ku_aktiv = 'X' and ku_vbnr in (:inSelekt);

Das ergibt den SQL-Fehler -302. Hat jemand eine Idee? (Die Klammern in den Selekt-String zu packen, hat auch nichts gebracht.

Dieter

[dschroeder]

Ich sehe gerade: So kann es natürlich nicht gehen, da das Feld ku_vbnr numerisch ist. Der Selektionsstring ist alpha. Geht das ganze mit numerischen Felder nicht? (Ich denke, ein Transformieren in Alpha ist zu langsam).

Meine eigentliche Aufgabenstellung ist die: Ich habe ein Array von numerischen Schlüsseln und möchte alle Datensätze lesen, die diesen Schlüsseln entsprechen.

Dieter

[andreaspr@aon.at]

Hallo Dieter,

du kannst dir ein dynamisches SQL zusammen basteln.

lg Andreas

[Fuerchau]

where Feld in (: V1, : V2, ... , : Vn) ...
Führe einfach alle Variablen auf.
initialisiere ggf. auf *LOVAL für nicht verwendetet Elemente.

[dschroeder]

@andreas:
Danke, aber dynamisches SQL wollte ich ja vermeiden.

[dschroeder]

@baldur:
Danke, die Idee ist mir noch nicht gekommen. Gut zu wissen, dass das geht. Aber das löst leider mein Problem nicht, da es theoretisch sehr viele Werte sein können (1000).

Dieter

[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