dynamisches qmqry

[Robi]

Hi *all

ich habe ein QMQRY mit

select f1, f2, f3 from datei where
f1 concat f2 concat f3 like &STRING

und ein CL, das eine Variable empfängt und so:
chgvar &STRING ('''%' *cat &VAR *TCAT '%''')
in die &STRING Variable übergibt

Lt. Debug steht in &STRING z.B. '%Hugo%' (incl. der hochkomma in der Var &String)

Bei selektionen in Großbuchstaben geht das
Bei selektionen in Gr. Klein geht das nicht

habe das f1 concat f2 concat f3 darauf in ein Upper() gepackt
Das ging zunächst
Wenn ich nun aber

fehlt im CB

als Var weggebe
sagt der Debug

&STRING = ''%fehlt im CB%'              '

aber ich bekomme keine Anzeige obwohl der string in F2 steht.

Wenn ich aber

ZYFLD1 EQ  AAA

weggebe bekomme ich auch eine Anzeige.

Daraufhin habe ich das qmqry so angepasst.

select f1, f2, f3 from datei where
upper(f1 concat f2 concat f3) like upper(&STRING)

nun scheint alles zu gehen

Was muß ich definieren, damit der upper wieder raus kann (Performance)

Danke
Robi

[Pikachu]

CHGJOB SRTSEQ(*LANGIDSHR)

[Robi]

Hallo Pikachu,

das wars nicht

Zwar stand mein Job auf *hex, aber das umstellen hat nix gebracht

noch ne Idee?
Robi

[Pikachu]

Zeig mal konkrete Beispieldaten und den SELECT mitsamt LIKE-Wert.

[Robi]

QMQRY

select f1, f2, f3, f4, f5 from datei where 
f1 concat f2 concat f3 concat f4 concat f5 like &STRING
order by rrn(datei) desc

CLLE

 pgm &STRING                                                     
 DCL &STRING *CHAR 30                                            
 CHGJOB SRTSEQ(*LANGIDSHR)                                       
 MONMSG CPF0000                                                  
              CHGVAR &STRING ('''%' *CAT &STRING *TCAT '%''')    
              STRQMQRY   QMQRY(MT940) SETVAR((STRING &STRING)) 
 ENDPGM

Aufruf
call cl (F4)

Eingabe
hme gef

Dateiinhalt in f4
Maßnahme gefunden

mit
QMQRY

select f1, f2, f3, f4, f5 from datei where 
upper(f1 concat f2 concat f3 concat f4 concat f5) like upper(&STRING)
order by rrn(datei) desc

geht es

Robi

[camouflage]

CHGVAR &STRING ('''%' *CAT &STRING *TCAT '%''')

auch wenn ich ein wenig altmodisch rüberkomme, diesen chgvar würde ich mit zwei variablen machen.

[Robi]

1. es muß nicht alt oder modern sein
2. es muß funktionieren und wartbar sein
3. wenn ich das ändere geht es auch nicht

Robi

[cbe]

Hallo Robi,

Was muß ich definieren, damit der upper wieder raus kann (Performance)

ich tippe drauf, dass die Performance nicht leidet, weil der STRING im SQL nur 1x am Anfang umgesetzt werden muss.

Ansonsten müsstest Du den String schon im Programm vorher auf GROSS umsetzen.

Tip: Ich habe mir für sowas ein Programm geschrieben, das
- Hochkomma drumrum macht,
- Zeichen auf GROSS umstellt
- enthaltene Hochkomma verdoppelt
dann brauche ich nicht mehr nachdenken.

Gruß, Christian

[Robi]

ich tippe drauf, dass die Performance nicht leidet, weil der STRING im SQL nur 1x am Anfang umgesetzt werden muss.

Nö, glaub ich nicht
ich hab doch 2 Upper da drin, 1 für den empfangen String und eins im where.

Performance spielt hier auch nicht die große Geige, ich wollte nur verhindern das jemand schreibt: ... sei zufrieden, es geht doch.

Warum zum Henker versteht das keine Gr.Klein Schrift

Robi

[cbe]

oh, stimmt, das erste UPPER habe ich glatt überlesen :-(

Dann hast Du wohl tatsächlich keine andere Chance, als die 2 UPPER.

Trotzdem - vergiss die Verdopplung der Hochkomma nicht, falls Dein String solche enthält.

[Fuerchau]

Ausserdem ist der "Order by rrn(x)" nicht performanceförderlich.

Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt.

[Robi]

vergiss die Verdopplung der Hochkomma nicht, falls Dein String solche enthält.

Ist bekannt, kommt aber nicht vor, BeforeTrigger verhindern das, schon wegen dem csv export.

Ausserdem ist der "Order by rrn(x)" nicht performanceförderlich.

Wenn das PF mit reusedltrcd(*no) erstellt wurde auch?

Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt

Ja, stimmt. Daran habe ich bei der Performance-Bemerkung nicht gedacht.

Trotzdem ...
Auch wenn ich in diesem Fall die Unterscheidung GROSS/klein nicht brauche...

Ist das Verhalten 'normal'? einstellbar? oder ein Fehler?

Robi