Mon soucis rapidement : j’ai une procédure stockée dont un des paramètres est utilisé dans un LIKE d’une clause WHERE. Genre ‹ XX% ›.
Le problème, c’est que ça ne marche pô. Eh oui.
Avec le ‹ XX% › en dur dans la proc oui mais passé en paramètre, non.
Après recherche, j’ai vu que d’autres que moi avaient eu le problème mais je n’ai pas trouvé pour autant de solution satisfaisante. En désespoir de cause je viens donc vous embêter avec mes soucis.
Des fois que ça aide, ma proc est sur DB2 400. Merci d’avance
ta requête est écrite en SQL Dynamique (concaténation de chaine grosso modo) ou en SQL normal ?
exemples oracles:
ok (sql “normal”):
Select toto into ma_variable from Ma_table where mon_champ like 'XX%'ok (sql dynamique):
pas ok (sql normal avec prise de paramètre): select toto from Ma_table where mon_champ like'mon_paramètre'
edit:
Il faut que tu utilises du sql dynamique ou au minimum des requêtes parametrées
.....'Select toto from Ma_table where mon_champ like :ma_variable_parametrée'...
puis une fonction de bind qui remplace :ma_variable_parametrée (noté par ':') par mon_paramètre
Ouh là. Déjà merci à toi phili_b. Mais en fait, je ne suis pas sûr de bien comprendre ta réponse. Moi en fait je dois me caser dans ton 3ième cas, à savoir qu’un de mes paramètres d’entrée (qui contient ‹ blup% › donc) alimente le LIKE. C’est pas bon alors ?
Sinon, je ne suis pas un sql masta mais je ne pense pas que ma DB2 cause le sql dynamique (que je ne suis pas sûr de bien comprendre d’ailleurs). Je vais me renseigner sur tout ça. Merci en tout cas !
ps : si tu avais des exemples sous la main, je ne cracherais pas d’ssus…
Ok bon alors j’ai eu une illumination hier soir, je mets la réponse des fois que ça serve.
Je précise bien le contexte parce je n’ai pas testé ailleurs : ma proc tourne sur DB2 400. Pour régler mon soucis, j’ai donc changé mon paramètre d’entrée de CHAR à VARCHAR, d’une chaîne toute conne vers une chaîne à taille variable.
Car oui, le problème était que dans le LIKE, les blancs à la fin de la chaîne ‹ blup% › (qui était donc plutôt ‹ blup%____ ›’) étaient interprétés. Avec un VARCHAR, ce n’est plus le cas. C’est d’une logique implacable mais je tombe dans le panneau à chaque fois que je touche à ce genre de truc.
Le mot de la fin : die iSeries, DIE !
Merci de votre attention (special thanks to phili_:P.
heu super ! de rien C’est clair que le CHAR par défaut rempli jusqu’au bout dans l’AS400 ça enerve quand on n’y pense pas.
Tu peux monter un extrait de ton souci dès fois que ça serve, stp ? Logiquement tu ne peux être qu’en SQL Dynamique ou tout au moins en SQL fait par concaténation de chaine de caractère. Je serais curieux de voir cela.
LEFT JOIN XPEUGNDTA/ZNNPDF00 AS PERSON1 ON MASTER.MABRNC = PERSON1.NPNACD
LEFT JOIN XPEUGNDTA/ZNNCDF00 AS COMPANY1 ON MASTER.MABRNC = COMPANY1.NCNACD
LEFT JOIN XPEUGNDTA/ZNNPDF00 AS PERSON2 ON MASTER.MAPNSN = PERSON2.NPNACD
WHERE
MASTER.MAPORF LIKE i_PolicyNum
/* Fin de la définition de la requete */
;[/code]
Mon problème se situait donc sur le type de i_PolicyNum (devenu donc VARCHAR au lieu de CHAR). Voilà.
[quote=“Tupperware_ass, post:6, topic: 26521”]CREATE PROCEDURE polsrch_proc
( IN i_RequestID CHAR(7),
IN i_PolicyNum VARCHAR(15))
[...]WHERE
MASTER.MAPORF LIKE i_PolicyNum;
Mon problème se situait donc sur le type de i_PolicyNum (devenu donc VARCHAR au lieu de CHAR). Voilà.[/quote]ha! Très intéressant. Ni en PL/SQL (Oracle) ni en Transact-SQL (SQL Server) tu ne peux pas faire cela, c’est-à-dire mélanger des variables et du code SQL, sauf en passant par ce que je t’ai dit. Mais en ProC (Oracle) je crois qu’on peut faire cela car le ProC est un précompilateur.
J’ai l’impression que c’est similaire en DB2 AS400, quand j’ai fait du DB2 UDB (Aix) il y avait le même concept si je ne m’abuse. Sous Unix(Aix) il fallait compiler les procédures SQL ensuite si je ne me trompe pas.
