sql - iniciales - ¿Por qué una consulta LIKE en Access no devuelve ningún registro?
like en sql ejemplos (4)
¿Hay alguna razón por la cual
SELECT * FROM MyTable WHERE [_Items] LIKE ''*SPI*''
no devuelve ningún registro con OleDbAdapter.Fill(DataSet) o OleDbCommand.ExecuteReader() ?
Cuando ejecuto el mismo SQL en MS Access directamente, devuelve los registros esperados. Además, en el mismo código, si cambio el SQL a
SELECT * FROM MyTable
Se devuelven todos los registros.
¡Dios mío, esto funciona! Muchas gracias.
Solo tuve que reemplazar los not like criteria a los not alike criteria .
Estoy compartiendo mi "historia" para ayudar a otros a encontrar esta publicación más fácil y guardarla de una búsqueda de dos horas.
Aunque he vinculado los archivos Excel 95-97 xls a la base de datos de Access 2010, y ejecuté create table e insert into consultas para importar todos los datos a una base de datos, por alguna extraña razón, la consulta de selección no pudo encontrar las cadenas I '' He escrito.
Intenté que not like "something" y not like "%something%" sin éxito, simplemente no funcionó.
L
Cambiar su * a % como % es la búsqueda de comodín cuando se usa OLE DB.
SELECT * FROM MyTable WHERE [_Items] LIKE ''%SPI%''
Intenta convertir tus caracteres comodín (*) a%
Esto debería solucionar el problema.
Intente cambiar LIKE to ALIKE y sus caracteres comodín de * a % .
El motor de base de datos de Access (Jet, ACE, lo que sea) tiene dos modos de consulta ANSI, cada uno de los cuales utiliza caracteres comodín diferentes para LIKE :
Usos del modo de consulta ANSI-89
*Modo de consulta ANSI-92 utiliza
%
OLE DB siempre usa el modo de consulta ANSI-92. DAO siempre utiliza el modo de consulta ANSI-89. La IU de acceso se puede configurar para usar una u otra.
Sin embargo, cuando se utiliza la palabra clave ALIKE el carácter comodín siempre es % independientemente del modo de consulta ANSI.
Considere una regla de negocios que establezca que un elemento de datos debe constar de exactamente ocho caracteres numéricos. Digamos que implementé la regla de la siguiente manera:
CREATE TABLE MyStuff
(
ID CHAR(8) NOT NULL,
CHECK (ID NOT LIKE ''%[!0-9]%'')
);
Es inevitable que use % como carácter comodín porque el tipo de datos CHAR de Access y las restricciones CHECK solo se pueden crear en el modo de consulta ANSI-92.
Sin embargo, alguien podría acceder a la base de datos utilizando DAO, que siempre utiliza el modo de consulta ANS-89, y el carácter % se consideraría un carácter literal en lugar de un carácter ''especial'', y se podría ejecutar el siguiente código:
INSERT INTO MyStuff (ID) VALUES (''%[!0-9]%'');
la inserción tendría éxito y mi integridad de los datos sería disparada :(
Lo mismo podría decirse utilizando LIKE y * en una Regla de validación creada en el Modo de consulta ANSI-89 y alguien que se conecta utilizando ADO, que siempre usa el Modo de consulta ANSI-92, e INSERTs un carácter * donde no debe estar un carácter * .
Por lo que sé, no hay forma de indicar qué modo de consulta ANSI se usa para acceder a la base de datos de Access. Por lo tanto, creo que todos los SQL deben codificarse para que se comporten de manera consistente, independientemente del modo de consulta ANSI elegido por el usuario.
Tenga en cuenta que no es demasiado difícil codificar para usar LIKE con el ejemplo anterior, por ejemplo,
CHECK (
ID NOT LIKE ''%[!0-9]%''
AND ID NOT LIKE ''*[!0-9]*''
)
... o incluso evitar completamente los comodines, por ejemplo
CHECK (ID LIKE ''[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'')
Sin embargo, el uso de ALIKE resultará en un código menos detallado, es decir, más fácil para el lector humano y, por lo tanto, más fácil de mantener.
Además, cuando llega el momento de ALIKE a un producto SQL que cumple con los estándares de SQL, ALIKE también se ALIKE bien, es decir, transformar la palabra clave ALIKE a LIKE es todo lo que se necesita. Cuando se analiza un predicado SQL dado, es mucho más fácil localizar la palabra clave LIKE en lugar de encontrar todas las múltiples instancias del carácter * en literales de texto. Recuerde que "portátil" no significa que "el código se ejecutará ''como está''"; más bien, es una medida de lo fácil que es mover el código entre plataformas (y tener en cuenta que moverse entre versiones del mismo producto es un puerto, por ejemplo, Jet 4.0 a ACE es un puerto porque la seguridad a nivel de usuario ya no funciona, los valores DECIMAL ordenar de manera diferente, etc).