generische Artikelsuche / subfileausgabe

[B.Hauser]

Hallo Andreas,

3 kleine Anmerkungen:

1. x'7D' für Hochkomma sollte vermieden werden, da dieser Hex-Code nicht international ist.
Statt x'7D' ein zwei Hochkomma benutzen.
Am besten man verwendet dafür eine Konstante.

2. Es sollte nicht auf SQLCOD = 0 sondern auf SQLCOD = 100 oder besser auf SQLSTT = '02000' abgefragt werden.
Zwischen Release V4R5M0 und Release V5R1M0 wurden einige Warnungen (SQLCOD 1-99) eingefügt.
Bei diesen Warnungen wird der Satz korrekt verarbeitet.
In Deinem Beispiel würde sogar die Schleife verlassen werden.

2. Sortierung und Auswahl unabhängig von Gross- und Klein-Schreibung steuert man eleganger über die Sort-Sequence:
C/Exec SQL
C+ Set Option SrtSeq = *LangIdShr
C/End-Exec

Bei dieser Variante ist die Verwendung der Skalaren Funktion UPPER nicht notwendig.

Überigens die Sortier-Reihenfolge kann man auch bei logischen Dateien angeben.

Birgitta

[AndreasH]

Hallo Britta,
danke für die Ergänzungen.
@Es sollte nicht auf SQLCOD = 0 ... abgefragt werden:
Ich werde meine "Schablone" nun auf SQLCOD >= 0 und <= 100 ändern.
Fix auf DOU SQLCOD = 0100 oder SQLSTT = '02000' als Schleifenbdingung würde die Gefahr einer Endlosschleife beinhalten, sollte ein anderer Programierer mal das Prepare statement ändern und der prepare nicht ausgeführt werden können wegen falschen Spaltennamen oder schlicht falschem Syntax.

@Sortierung und Auswahl unabhängig von Gross- und Klein-Schreibung steuert man eleganter über die Sort-Sequence:


C/Exec SQL
C+ Set Option SrtSeq = *LangIdShr
C/End-Exec

Dabei wird Groß- Kleinschreibung zwar für die Sortierung benutzt, aber nicht für die Selektion.
SELECT * FROM DATEI WHERE Feld like '%eV%'
findet Satz Feld = "Germania eV" aber nicht Satz Feld = "German DEVELOPMENT".
Mein Ansatz war dahingehend, beide zu finden.

@1. x'7D' für Hochkomma sollte vermieden werden, da dieser Hex-Code nicht international ist.
Wieder was dazu gelernt. Habe bisher immer HY als Const(X'7D') definiert, Const('''') ab jetzt

[Fuerchau]

Wenn man nicht Case-Sensitive suchen will, kann man halt mit "upper(myfield) like upper(trim(:mykrit))" suchen.

Und was die verwendbaren Zeichen in einer Programmquelle angeht, hier noch mal der Link:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/nls/rbagsinvariantcharset.htm

[B.Hauser]

Hallo Andreas,

hast Du die Sortier-Reihenfolge auch wirklich auf *LangIdShr gesetzt und nicht versehentlich *LangIdUnq verwendet?

Im 1. Fall ,wird unabhängig von Gross-und Kleinschreibung sortiert und auch selektiert.
--> Also 'MEIER', 'Meier' und 'meier' werden mit LIKE '%meier%' selektiert.

Im 2.Fall wird unabhängig von Gross-und Kleinschreibung sortiert, jedoch 'Meier', 'MEIER' und 'meier'
werden bei der Selektion unterschiedlich behandelt.
--> Also bei LIKE '%meier%' wird auch nur 'meier' ausgewählt.

Probier's am besten mal interaktiv aus. Sortierreihenfolge beim STRSQL oder über F13 festlegen.

Birgitta

[AndreasH]

Hallo Birgitta,
ja:
STRSQL SRTSEQ(*LANGIDSHR)


select * from kbddta/bssb00 WHERE sbuser like '%eV%'
bringt keine Ergebnisse


select * from kbddta/bssb00 WHERE sbuser like '%EV%'
bringt ca 600 Sätze.

Beide inaktiv getestet. Nu kommt der Hammer: Geht nicht, wenn ich das bei STRSQL als Aufrufparameter mitgebe, sondern nur, wenn ich mit F13 Sitzungsattribute verändere *grummel*
Also, ich nehm alles zurück und behaupte das Gegenteil :rolleyes:

Gruß