Problem sprowadza się do tego, czy używasz char lub varchar2 semantyka porównawcza w zapytaniach. Jeśli masz zakodowany na stałe literał ciągu lub char(10) zmienna Oracle używa char semantyki porównania, które mają ignorować końcowe białe znaki. Jeśli masz varchar2(10) zmienna Oracle używa varchar2 semantyka porównania, która obejmuje końcowe białe znaki. Tak więc
select aa
into v_temp
from abc
where aa in (v_aa);
zwróci wiersz, jeśli v_aa jest zdefiniowany jako char(10) (lub jeśli jest zastąpiony literałem ciągu), ale nie, jeśli jest zdefiniowany jako varchar(10) .
Jest to jeden z (wielu) powodów, dla których większość ludzi unika char typy danych całkowicie. Osobiście nie przeszkadza mi okazjonalny char dla danych o naprawdę stałej szerokości (np. char(1) dla flag i char(2) dla kodów stanów), nawet jeśli nie ma żadnych korzyści z używania char ponad varchar2 w tych scenariuszach. Jednak dla wszystkiego, co nie ma stałej szerokości, użyj char nie ma sensu. Po prostu zmuszasz Oracle do zajmowania większej ilości miejsca niż to konieczne i tworzenia większej ilości pracy dla siebie, radzenia sobie z dwoma zestawami semantyki porównywania ciągów (między innymi problemami).
