Le problème est de savoir si vous utilisez char ou varchar2 sémantique de comparaison dans vos requêtes. Si vous avez un littéral de chaîne codé en dur ou un char(10) variable, Oracle utilise le char sémantique de comparaison qui doit ignorer l'espace blanc de fin. Si vous avez un varchar2(10) variable, Oracle utilise le varchar2 sémantique de comparaison qui inclut l'espace blanc de fin. Ainsi
select aa
into v_temp
from abc
where aa in (v_aa);
renverra une ligne si v_aa est défini comme un char(10) (ou s'il est remplacé par un littéral de chaîne) mais pas s'il est défini comme un varchar(10) .
C'est l'une des (nombreuses) raisons pour lesquelles la plupart des gens évitent char types de données entièrement. Personnellement, les char occasionnels ne me dérangent pas pour des données vraiment à largeur fixe (c'est-à-dire char(1) pour les drapeaux et char(2) pour les codes d'état) même s'il n'y a aucun avantage à utiliser char sur varchar2 dans ces scénarios. Pour tout ce qui n'est pas à largeur fixe, cependant, en utilisant un char ça n'a aucun sens. Vous ne faites qu'obliger Oracle à consommer plus d'espace qu'il n'en a besoin et à créer plus de travail pour vous-même en traitant deux ensembles de sémantiques de comparaison de chaînes (entre autres problèmes).
