Frage zu Query

[alex61]

Hallo zusammen,

habe wieder mal eine Frage, diesmal zum Query:

Gibt es eine Möglichkeit bei einem Query nicht Case Sensitiv abzufragen, sondern wenn z.b. klein geschrieben wurde, auch die großgeschriebenen Einträge zu erhalten ?

Beispiel: wenn ich nach like 'bm%' frage, das ich auch die Einträge mit 'BM' bekomme

Für Infos wäre ich wie immer dankbar.

Grüße A.

[Robi]

nimm SQL,
zur Not mit QMQRY die abfrage bauen und nach SQL umstellen lassen.
Dann die Where Bedingung ergänzen
... where upper(Feld) like 'BM%'

[Fuerchau]

Da Query auch Views abfragen kann, musst du eine View mit berechneten Feldern, z.B. UPPER(NAME) as NAME, definieren. Dann klappt das auch.
Einfacher ist sicherlich SQL.
Der Vorteil von Query, Ausgabedateien erstellen zu lassen geht ja auch inzwischen mit SQL:

create table bla as
(select * from blub where ...)
with data.

Vorsicht beim Umstellen von QRYDFN mit SQL-Erstellung.
Die diversen Verknüpfungen von Query werden gerne als Inner Join, statt z.B. left join erzeugt.

[alex61]

danke schon mal an alle Helfenden. Ich probiere das alles mal aus. Schönen Abend noch.

[Pikachu]

Vielleicht genügt es schon im Query als Sortierfolge die Auswahl 2=Query für IBM i Deutsch auszuwählen!?

[Fuerchau]

Stimmt, das beträfe dann alle Felder:
https://www.ibm.com/docs/de/i/7.5?to...-sort-sequence

[KingofKning]

Ich weiß ja nicht wie oft ich den Text lesen muß um ihn zu verstehen. Vermutlich werde ich alt:

IBM DB2 Query Manager and SQL Development Kit for i

Das Lizenzprogramm IBM® Db2® Query Manager and SQL Development Kit for i nimmt keine bestimmte CCSID an, wenn die Quelle vorkompiliert wird. Es wird davon ausgegangen, dass alle Variantenzeichen in der Sprachsyntax, wie z. B. das Symbol nicht (¬), in der CCSID der Quellendatei codiert sind.
Wenn die Quellendatei beispielsweise die CCSID 00037 hat, wird das Symbol not korrekt als Codepunkt X'5F' interpretiert. Wenn die Quellendatei jedoch eine CCSID von 00500 hat, wird das Symbol nicht korrekt als Codepunkt X'BA ' interpretiert.
Ein Literal wird in der CCSID der Quellendatei gespeichert.
Das Lizenzprogramm IBM Db2 Query Manager and SQL Development Kit for i ruft den Compiler für die entsprechende Sprache auf, um ein SQL-Programm zu erstellen. Daher müssen Sie die allgemeinen Richtlinien für höhere Programmiersprachen beachten.


GG 2634

[BenderD]

Ich weiß ja nicht wie oft ich den Text lesen muß um ihn zu verstehen. Vermutlich werde ich alt:

IBM DB2 Query Manager and SQL Development Kit for i

Das Lizenzprogramm IBM® Db2® Query Manager and SQL Development Kit for i nimmt keine bestimmte CCSID an, wenn die Quelle vorkompiliert wird. Es wird davon ausgegangen, dass alle Variantenzeichen in der Sprachsyntax, wie z. B. das Symbol nicht (¬), in der CCSID der Quellendatei codiert sind.
Wenn die Quellendatei beispielsweise die CCSID 00037 hat, wird das Symbol not korrekt als Codepunkt X'5F' interpretiert. Wenn die Quellendatei jedoch eine CCSID von 00500 hat, wird das Symbol nicht korrekt als Codepunkt X'BA ' interpretiert.
Ein Literal wird in der CCSID der Quellendatei gespeichert.
Das Lizenzprogramm IBM Db2 Query Manager and SQL Development Kit for i ruft den Compiler für die entsprechende Sprache auf, um ein SQL-Programm zu erstellen. Daher müssen Sie die allgemeinen Richtlinien für höhere Programmiersprachen beachten.


GG 2634

... das ist dasselbe, wie bei Programmen mit embedded SQL. Da wird ebenfalls die CCSID der Quelldatei an die Datenbank weitergegeben, die dann alles in diese CCSID umsetzt, was nicht explizit gecastet wird.

D*B

PS: zum eigentlichen Thema: gab's da nicht die Uralt Variante mit einer gefummelten Sortierfolge?

[Fuerchau]

I.d.R. sind Textkonstanten in der CCSID der Quelldatei kodiert.
Nun kann es theoretisch vorkommen, dass Copy-Quellen eine abweichende CCSID aufweisen.
Passieren tut folgendes:
Ist der Job zur Kompilierzeit mit CCSID 65535 kodiert, erfolgt beim Lesen der Quelle keine Umwandlung in die JOB-CCSID. Die beteiligten Kopierstrecken werden laut IBM in die CCSID der 1. Quelle gewandelt.
Hat der Job eine CCSID wie 1141, erfolgt wie immer beim Lesen eine Umwandlung der Quellen in die Job-CCSID.
Nun kommt es auf die Laufzeitumgebung an!
Hat der Job zur Laufzeit die CCSID 1141 erfolgt beim Lesen und Schreiben immer eine Umwandlung von/in den Job und die eingebettete Konstante passt.
Hat der Job aber zur Laufzeit z.B. die CCSID 037 wird die eingebettete Konstante von 037 in die CCSID 1141 der Tabelle gewandelt, was allerdings einen vollkommen anderen Codewert bedeutet.

Dies ist unter den sog. varianten Zeichen einer Codetabelle zu verstehen. Dies sind Zeichen, die je nach CCSID einen anderen Codepoint, also Hexwert, aufweisen.

Es gibt daher die Empfehlung:
Textkonstanten in Programmen mit varianten Zeichen zu vermeiden und zur Laufzeit aus einer Tabelle mit CCSID zu lesen.
Desweiteren ist es grundsätzlich erforderlich dass jeder Job eine von 65535 abweichende CCSID haben muss, was i.d.R. durch den Systemwert QCCSID oder den Sprachschlüssel im Userprofil definiert wird.

Aber das erzähle ich hier ja bereits seit über 20 Jahren;-).

[BenderD]

I.d.R. sind Textkonstanten in der CCSID der Quelldatei kodiert.
Nun kann es theoretisch vorkommen, dass Copy-Quellen eine abweichende CCSID aufweisen.
Passieren tut folgendes:
Ist der Job zur Kompilierzeit mit CCSID 65535 kodiert, erfolgt beim Lesen der Quelle keine Umwandlung in die JOB-CCSID. Die beteiligten Kopierstrecken werden laut IBM in die CCSID der 1. Quelle gewandelt.
Hat der Job eine CCSID wie 1141, erfolgt wie immer beim Lesen eine Umwandlung der Quellen in die Job-CCSID.
Nun kommt es auf die Laufzeitumgebung an!
Hat der Job zur Laufzeit die CCSID 1141 erfolgt beim Lesen und Schreiben immer eine Umwandlung von/in den Job und die eingebettete Konstante passt.
Hat der Job aber zur Laufzeit z.B. die CCSID 037 wird die eingebettete Konstante von 037 in die CCSID 1141 der Tabelle gewandelt, was allerdings einen vollkommen anderen Codewert bedeutet.

Dies ist unter den sog. varianten Zeichen einer Codetabelle zu verstehen. Dies sind Zeichen, die je nach CCSID einen anderen Codepoint, also Hexwert, aufweisen.

Es gibt daher die Empfehlung:
Textkonstanten in Programmen mit varianten Zeichen zu vermeiden und zur Laufzeit aus einer Tabelle mit CCSID zu lesen.
Desweiteren ist es grundsätzlich erforderlich dass jeder Job eine von 65535 abweichende CCSID haben muss, was i.d.R. durch den Systemwert QCCSID oder den Sprachschlüssel im Userprofil definiert wird.

Aber das erzähle ich hier ja bereits seit über 20 Jahren;-).

... das dumme ist nur, dass das im Client Server Umfeld nicht immer funktioniert, da die CCSID des anfordernden Jobs nicht weitergegeben wird, sondern die CCSID der Quelldatei. (Wie ich bei ArdGate leider feststellen musste). Da kommt man dann wieder mit Unicode drumherum.

D*B

[KingofKning]

Stimmt. Mich dünkt Du sagtest es bereits das ein oder ander mal ;-)

[Fuerchau]

Ja, stimmt auch.
Seit ILE wird die CCSID der Quelldatei im Modul vermerkt, das kann man auch nachsehen.
Wenn allerdings der Job trotzdem auf Hex 65535 steht und man Unicodedaten in A-Variablen lesen will, streikt das System, da ja die Zielccsid unbekannt ist, denn beim Lesen/Schreiben gilt die Job-CCSID.
Die Quell-CCSD wird anscheinend nur bei Konstanten verwendet.
Du kannst das Feld natürlich als UCS2 mit CSID 1200 definieren. Aber auch die Runtime will dann bei einem Move/Eval von/in A-Felder eine gültige CCSID haben.