Firebird: Problema con LIKE

[[rretamar]]

Hola.
Estoy usando Firebird 1.5 con una tabla, ejecutando una sentencia LIKE de la siguiente forma:

Select * From Tabla
Where Campo Like '%6000'

Campo es un campo de tipo cadena (string), y en distintos registros están los valores 426000, entre otros. En este caso, la consulta me devuelve cero registros, mientras que si uso (por ejemplo) LIKE '426%' sí me funciona.

La pregunta es entonces: ¿ El caracter "comodín" (wilcard) % no funciona al inicio ?.

Saludetes...

[[ArdiIIa]]

todos los que acaban en 46

Código SQL [-]
SELECT * FROM CODIGOS_POSTALES
WHERE CODIGO like '%46'
ORDER BY CODIGO

Todos los que comienzan por 46

Código SQL [-]
SELECT * FROM CODIGOS_POSTALES
WHERE CODIGO like '46%'
ORDER BY CODIGO

Todos los que contienen 46 --- También valido like '%46%'

Código SQL [-]
SELECT * FROM CODIGOS_POSTALES
WHERE CODIGO CONTAINING '46'
ORDER BY CODIGO

[[rretamar]]

A primera vista debería ser así, pero de las opciones que pones, la primera es la que me devuelve como resultado cero registros.

A la consulta la tipeo directamente desde el editor de SQL de IbExpert.

Saludetes....

[[ArdiIIa]]

Pues a primera vista, parece que no tienes registros que cumplan esa condición ??

[[rretamar]]

Aclaración: Campo es del tipo Char[30]

Sí, existen registros que cumplen la condición. La única forma de obtener resultados es hacer lo siguiente:

Select * From Tabla
Where Campo Like '%6000 ......24 espacios...... '

Porque como decía antes, si hago:

Select * From Tabla
Where Campo Like '%6000'

No obtengo resultados

Lo extraño es que al momento de cargar un valor en el campo, no he cargado esos espacios al final (al editar la tabla en una grilla tampoco aparecen). Estoy usando INSERT INTO para cargar los valores.

Saludetes....

[[ArdiIIa]]

Una aclaración... en lo de antes...
También valido like '%abc%' no es lo mismo que '%ABC%', en cambio en CONTAINING esto no importa....


En lo que me comentas

Código SQL [-]
Select * From Tabla
Where Campo Like '%6000 ......24 espacios...... '

No entiendo porque te puede pasar...

[TJose]

Qué sucede si cambias char(30) por varchar(30)

TJose

[[Lepe]]

Precisamente ahí está el truquito.

Cualquier campo declarado con char(30) la base de datos lo rellena con espacios, hasta el límite declarado (en este caso 30).

Sin embargo con varchar(30) la base de datos se comportará exactamente como deseas, solo guardará los carácteres que hayas introducido (sin rellenar con espacios).

Saludos

[[rretamar]]

Muchas gracias a todos los que respondieron.

He realizado la misma prueba usando el dialecto SQL local del BDE (con una ta bla Paradox) y el error no se produce.

Es evidente que se me está rellenando con espacios el resto de los caracteres del campo.

Probaré reemplazar CHAR por VARCHAR (confieso que nunca usé ese tipo de datos). ¿ Este cambio puede tener algún inconveniente en cuanto a performance, espacio ocupado o algo similar ?

Saludos cordiales desde Argentina,

[[Lepe]]

Inconvenientes ninguno, eso si, deberás usar el collate ES_ES (o el de tu país), pero vamos, que eso es normal en char o varchar. Te sugiero crear un dominio y partir de ahí, ya que te será más cómodo asignar un dominio que establecer todas las propiedades a mano .

Incluso se podría decir que es más eficiente, ya que el SGBD no tendrá que añadir espacios ni quitarlos al mostrar los datos.

Quizás al pasar los datos del campo char hacia el campo varchar se incluyan esos espacios en blanco, no lo sé porque no he trabajado con tipos char.

Saludos

[[rretamar]]

Probé modificar los campos CHAR[30] por VARCHAR[30] en registros ya existentes pero el resultado fue el mismo (como si al realizar el cambio de formato del campo, los espacios en blanco siguieran estando al final del valor).

Entonces borré todos los registros (es una tabla de pruebas...), como para empezar a insertar directamente valores en los campos VARCHAR[30] y voila !!! ahora puedo usar LIKE '%STRING' y obtener los resultados esperados.

Muchas gracias por la ayuda recibida.

Saludos desde Argentina...

[rastafarey]

No era necesaro borrar los registro

Simplemte debias actualizar el campo con un sql usando la funcion trim