[NEWSboard IBMi Forum]

Thema: SQL Upper

  1. #1
    Registriert seit
    Jan 2008
    Beiträge
    58

    SQL Upper

    Hallo *All,
    ich habe was "interessantes" bei interaktivem SQL entdeckt.
    Mit :

    select * from LAGERORTE
    where posstr(upper(TEXT), upper('Hängelager‘)) > 0

    bekomme ich das Ergebnis = 0, aber mit :

    select * from LAGERORTE
    where posstr(upper(TEXT), upper('ngelager‘)) > 0

    bekomme ich 71 Sätze angezeigt.

    Habt Ihr schon so was gehabt ?
    Woran liegt das ?

    Mit digitalen Grüßen
    Andreas

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    An deiner inkorrekten CCSID.
    Das "ä" hängt von der CCSID ab.
    Je nach aktuellen CCSID's zur Laufzeit passt das halt nicht.
    Vergleiche die CCSID des Feldes/der Datei mit der CCSID deines Jobs und deines Bildschirmes (hier Codepage).
    Passen diese zueinander dann klappts auch mit den Umlauten.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Jan 2008
    Beiträge
    58
    Hallo Fuerchau,
    mittlerweile habe ich es auch rausbekommen - Zeichensatz-ID im Benutzerprofil auf 1141 geändert.
    Es ist aber gefährlich, wenn man eine Auswertung (für den Chef :-) ) machen soll - weil keine Sätze gefunden werden.
    Übrigens, in einem SQLRPG geht die Anweisung korrekt, sogar in der gleichen CA Sitzung.

    Schöne Grüße

    Andreas

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Es war schon immer gefährlich, nicht auf eine korrekte CCSID zur Laufzeit zu achten, das ist also nichts neues.
    Der Zeichensatz im Benutzerprofil ist i.d.R. unnötig, da ein Job eine CCSID passend zur Datenbank haben sollte und diesen eigentlich aus QCCSID bekommt.
    Leider werden die Systeme aber sehr sehr häufig mit QCCSID 65535 betrieben und man wundert sich dann über seltsame CCSID-Fehler, die gar nicht so seltsam sind.

    Generell gilt immer folgendes:
    Zwischen Job und Device gibt es keine CCSID-Umsetzung (sowohl DSPF als auch PRTF).
    Zwischen CCSID 65535 und einer andern CCSID gibt es generell keine Umsetzung.
    Zwischen CCSID x und CCSID y gibt es eine Umsetzung falls diese kompatibel sind. Seit V6 wird u.U. UCS2 als Zwischenschritt automatisch angewendet.

    Und das selbe gilt auch für Programm-Quellen!
    D.h., dass zur Compilezeit Umlaute und Sonderzeichen ggf. umgewandelt werden, zur Laufzeit werden diese aber grundsätzlich binär betrachtet. Was da auch durchaus zu Problemen kommen kann.

    Da es für SQL nie ohne CCSID geht, nimmt STRSQL (also der Dialog) zur Laufzeit bei fehlender CCSID ggf. 037 (US-Englisch) an (was leider nicht dokumentiert ist). Somit wird das nicht umgewandelte "ä" aus dem Bildschirm von 037 in 273 gewandelt was, glaube ich, dem Zeichen "[" entspricht.

    Dein Programm aber reicht die Daten einfach nur an SQL transparent weiter.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •