El problema se reduce a si usa char o varchar2 semántica de comparación en sus consultas. Si tiene un literal de cadena codificado de forma rígida o un char(10) variable, Oracle usa el char semántica de comparación que debe ignorar el espacio en blanco final. Si tiene un varchar2(10) variable, Oracle usa el varchar2 semántica de comparación que incluye el espacio en blanco final. Así
select aa
into v_temp
from abc
where aa in (v_aa);
devolverá una fila si v_aa se define como un char(10) (o si se reemplaza con un literal de cadena) pero no si se define como varchar(10) .
Esta es una de las (muchas) razones por las que la mayoría de la gente evita char tipos de datos por completo. Personalmente, no me importa el char ocasional para datos verdaderamente de ancho fijo (es decir, char(1) para banderas y char(2) para códigos de estado) aunque no hay ningún beneficio en usar char sobre varchar2 en esos escenarios. Sin embargo, para cualquier cosa que no sea de ancho fijo, use un char no tiene sentido. Simplemente está obligando a Oracle a consumir más espacio del que necesita y creando más trabajo para usted al lidiar con dos conjuntos de semántica de comparación de cadenas (entre otros problemas).
