iSeries + MS Access

[Fuerchau]

Wichtig ist noch folgendes:
wenn du mit

MyName = '%Müller%';
und
select ... where ... upper(KDNAME) like upper(:MyName) ...

suchst, kommt auch nicht unbedingt das gewünschte Ergebnis, da die Variable MyName noch Leerzeichen am Ende enthält, die auf jeden Fall mitgesucht wird !
Ergänze daher:

select ... where ... upper(KDNAME) like upper(trim(:MyName)) ...

*LANGIDSHR gibt dann Probleme, wenn es keine LF mit diesem Attribut gibt. Ich habe das mal ausprobiert und die Performance ging drastisch in den Keller da auf jeden Fall erst mal ein temporärer Index aufgebaut wurde.
Also in solchen Fällen besser eine LF mit diesem Attribut erstellen und den SQL sogar auf diese LF loslassen.

[BenderD]

Hallo,

generell brauchen solche Queries einen statischen Index, wenns brummen soll!!!
Beim CREATE INDEX wird die Sortierfolge die aktuell gültig ist, verwendet und in dem Index verdrahtet und nur wenn der mit dem zur Laufzeit passt, wird er verwendet. Zusätzlich ist noch mit zu beachten, dass der (sogenannte) Query Optimizer bei der Verwendung von Feldfunktionen eher als Query Pessimizer fungiert.

mfg

Dieter Bender

Wichtig ist noch folgendes:
wenn du mit

MyName = '%Müller%';
und
select ... where ... upper(KDNAME) like upper(:MyName) ...

suchst, kommt auch nicht unbedingt das gewünschte Ergebnis, da die Variable MyName noch Leerzeichen am Ende enthält, die auf jeden Fall mitgesucht wird !
Ergänze daher:

select ... where ... upper(KDNAME) like upper(trim(:MyName)) ...

*LANGIDSHR gibt dann Probleme, wenn es keine LF mit diesem Attribut gibt. Ich habe das mal ausprobiert und die Performance ging drastisch in den Keller da auf jeden Fall erst mal ein temporärer Index aufgebaut wurde.
Also in solchen Fällen besser eine LF mit diesem Attribut erstellen und den SQL sogar auf diese LF loslassen.

[reraru]

Vielen Dank Euch beiden!

Ich wollte gerade mal eben die SQL Referenz auf den Drucker jagen. Tse! 1100 Seiten? Das macht bei Duplex immerhin noch 550. Ok! Das lasse ich lieber! ; - )

@ Birgitta:
Ich danke Dir für den LINK! Den hätte ich sonst nie auf den IBM Websites gefunden! No Way!

Was die Änderung der Sortierfolge angeht: Das werde ich mir mal anschauen!

@ BenderD:
OK!! ;-)

@ Fuerchau:
Ich habe die Trim Funktion mal ergänzt. Die Frage währe noch, ob folgendes nicht sinnvoll ist:

select ... where ... upper(trim(KDNAME)) like upper(trim(:MyName))

Bei Deiner Variante werden doch nur bei Variable die Leerzeichen gekürzt, oder? Nicht aber beim Feldwert.

Was ist hier sinnvoll?

Gruß René

[Fuerchau]

Da der LIKE ja einem SCAN nahe kommt, ist ein TRIM des Suchfeldes nicht erforderlich. Für eine Zugriffsoptimierung ist das sogar NICHT ratsam.

[reraru]

Hi Fuerchau!

Ich danke!!!

Gruß René