emb. SQL und UTF-16

[Fuerchau]

Also ALLE Datensätze kann ich mir fast nicht vorstellen. Da muss der Select irgendwo falsch sein.

Probiere das erst mal mit STRSQL aus.
Ggf. musst du die Felder erst wieder in UCS2 casten:

where upper(cast(feld as graphic(nn) ccsid 13488)) = 'TOP'

Allerdings ist hier das Problem, dass die Konstante 'TOP' nicht UCS2 ist !
Also ist die ggf. auch zu casten.

Das Hauptproblem ist, das der UCS2-SQL-String erst in Job-CCSID konvertiert wird und nicht so als UCS2 verwendet wird.
UCS2-Felder funktionieren nur als Hostvariablen (CLI-Interface) und leider nicht bei dynamischem SQL.

Du kannst dir das mit der %UCS2 für das Statement schenken.

[tsh1970]

Versuche ich unter STRSQL alle mögliche Formen des Cast's wie z.B.:
select * from MDPROP03
where cast(TITITL as graphic(60) ccsid 13488)
= cast('Top' as graphic(60) ccsid 13488)

Erhalte ich immer die Fehlermeldung:
Zeichenumsetzung zwischen CCSID 65535 und CCSID 13488 ungültig.

Folgendes funktioniert unter STRSQL:
select * from MDPROP03 where cast(TITITL as char(20)) = 'Top'
select * from MDPROP03 where UPPER(cast(TITITL as char(60))) = cast('TOP' as char(60))
wäre aber unsinnig da ich eben auch Unicode Zeichen bekomme,die beim Cast auf CHAR "verschluckt" werden.

Führe ich das ganze im Programm aus: Zeigt mir der Debugger
SQLStatement =
select * from MDPROP03 where UPPER(cast(TITITL as char(60))) = cast('TOP' as char(60))

und ich bekomme folgende Fehlermeldung beim Prepare Cursor
SQLCODE: -104, SQLSTATE: 42601, SQLERRMC: AS
andere Abfragen die ich mit der gleichen Routine zusammenbaue funktionieren korrekt, wenn ich eben kein Graphic Feld abzufragen versuche.

Ich versteh die Welt nicht mehr...

[Fuerchau]

Wichtig ist, dass dein Job nicht mit CCSID 65535 läuft !!!
Wie soll SQL da korrekt umsetzen können ?

[tsh1970]

Okay das ist klar, habe ich im Eifer des Gefechtes schlichtweg übersehen.

Der Job unter dem das Ganze passiert läuft unter der CCSID 1141.

Die CCSID des Feldes ist 1200.

zum SQL-104: wenn ich das SQL aus dem Feld Sql-Statement direkt im SQL eingebe bekomme ich keinen Fehler.

zum %UCS2 bzw. die Arie
Das Feld TITITL hat die CCSID 1200, baue ich mir den SQlStatement String ohne %UCS2 zusammen bekomme ich die Meldung *RNF7421 30 1 Operanden sind mit der Art des Operators nicht kompatibel. Deswegen die %UCS Arie.
Wenn jemand einen anderen Weg kennt bin ich dankbar.

Das mit allen Sätzen könnte ein Folgefehler nach dem FetchCsr sein.

[tsh1970]

Ich denke ich habe die Ursache des Problems gefunden:

Und zwar in der Definition des SQLStatements.
Dieses war als SqlStatement s 5000C VARYING definiert nach dem ich es auf 5000 Alpha angepasst habe, bekomme ich nun das gewünschte Ergebnis.

[tsh1970]

Nun noch eine Frage, zum LIKE, CAST und CCSID 1200.

Wenn mein SQL "....where UPPER(cast(TITITL as graphic(60) ccsid 1200)) like cast('%TOP%' as graphic(60) ccsid 1200) " lautet, bekomme ich nur den Titel der genau TOP heißt. Andere Titel in der Tabelle die z.B. "stops" enthalten werden nicht angezeigt.
Meine Vermutung läuft dahin dass das '%' nicht in im Cast sein darf.
Aber wie lautet der String dann? Mit

select * from  MDPROP03                                    
where upper(cast(TITITL as graphic(60) ccsid 1200))        
like ('%'||cast('TOP'  as graphic(60) ccsid 1200)||'%')    
SELECT * FROM MDPROP03 
WHERE upper(cast(TITITL as graphic(60) ccsid 1200)) 
like '%' CONCAT cast('TOP' as graphic(60) ccsid 1200) 
CONCAT '%'

bekomme ich das gleiche Ergebnis.

[BenderD]

select ... where ... like ?
preparen und anchließend open ... using :myHostVar
sollte da eigentlich funzen, dann fällt die UCS Casterei wieder weg und myHostVar muss dann ein graphic Feld sein.

D*B

Nun noch eine Frage, zum LIKE, CAST und CCSID 1200.

Wenn mein SQL "....where UPPER(cast(TITITL as graphic(60) ccsid 1200)) like cast('%TOP%' as graphic(60) ccsid 1200) " lautet, bekomme ich nur den Titel der genau TOP heißt. Andere Titel in der Tabelle die z.B. "stops" enthalten werden nicht angezeigt.
Meine Vermutung läuft dahin dass das '%' nicht in im Cast sein darf.
Aber wie lautet der String dann? Mit

select * from  MDPROP03                                    
where upper(cast(TITITL as graphic(60) ccsid 1200))        
like ('%'||cast('TOP'  as graphic(60) ccsid 1200)||'%')    
SELECT * FROM MDPROP03 
WHERE upper(cast(TITITL as graphic(60) ccsid 1200)) 
like '%' CONCAT cast('TOP' as graphic(60) ccsid 1200) 
CONCAT '%'

bekomme ich das gleiche Ergebnis.

[Fuerchau]

Das Problem beim casten ist die fixe Länge an stelle von VARGRAPHIC bzw. VARCHAR.
Dadurch wird rechstbündig mit Leerzeichen aufgefüllt, die natürlich zum Suchmuster dazugehören.

AUch bei Hostvariablen ist ggf. die Definition varying erforderlich oder im SQL ein trim(: MyHstVar) !

[Fuerchau]

Nachtrag:
Wenn du ohne Hostvars arbeitest und deinen SQL zusammenstrickst, wird das Ganze nur mit invarianten Zeichen in den Konstanten korrekt funktionieren.
Umlaute und andere Sonderzeichen werden Probleme bereiten.

Einzig die Verwendung einer UCS2-Hostvariablen als Parameter wird sicher über alle Sprachgrenzen hinweg funktionieren.

[tsh1970]

okay das wars, vielen Dank
mit folgenden Select klappts zu voller Zufriedenheit:

select * from MDPROP03                                     
where upper(cast(TITITL as graphic(60) ccsid 1200))        
like trim(cast('%TOP%' as graphic(60) ccsid 1200))

Eine Umstellung auf HostVars werde ich nun als nächstes in Angriff nehmen.

[Fuerchau]

Zu beachten ist aus Performancegründen dass Funktionen auf Felder in der Where-Klauses wie UPPER, CAST u.ä. die Verwendung eines Indexes verhindern.

[BenderD]

a) dös is hier Wurscht (like %irgendwas führt eh zum full table scan)
b) wat mutt dat mutt
c) eine halbwegs intelligente Query Engine sollte sich da (hoffentlich) ratz fatz den erforderlichen Zugriffspfad von einem (hoffentlich) vorhandenen Index ableiten können.

D*B

Zu beachten ist aus Performancegründen dass Funktionen auf Felder in der Where-Klauses wie UPPER, CAST u.ä. die Verwendung eines Indexes verhindern.