¿Cómo puedo hacer que MS Access Query Parameters sea opcional?

Tengo una consulta que me gustaría filtrar de diferentes maneras en diferentes momentos. La forma en que lo he hecho ahora mismo al colocar parámetros en el campo de criterios de los campos de consulta relevantes, sin embargo, hay muchos casos en los que no deseo filtrar en un campo dado, sino solo en los otros campos. ¿Hay algún modo de que se pueda pasar un comodín de algún tipo al parámetro de criterios para que pueda eludir el filtrado para esa llamada particular de la consulta?

0
agregado editado
Puntos de vista: 1

6 Respuestas

No estoy seguro de que esto ayude, porque sospecho que quieres hacer esto con una consulta guardada en lugar de hacerlo en VBA; sin embargo, lo más fácil que puede hacer es crear una consulta línea por línea en VBA y luego crear un conjunto de registros a partir de ella.

Una forma bastante hackosa sería volver a escribir la consulta guardada sobre la marcha y luego acceder a eso; sin embargo, si tiene varias personas que usan la misma base de datos, puede tener conflictos y confundirá al siguiente desarrollador.

También podría pasar programáticamente el valor predeterminado a la consulta (como se discutió en su pregunta anterior)

0
agregado

Volver a mi examen anterior en su pregunta anterior. Tu consulta parametrizada es una cadena que se parece a eso:

qr = "Select Tbl_Country.* From Tbl_Country WHERE id_Country = [fid_country]"

dependiendo de la naturaleza de fid_Country (número, texto, guía, fecha, etc.), deberá reemplazarlo por un valor comodín y caracteres de delimitación específicos:

qr = replace(qr,"[fid_country]","""*""")

Para permitir completamente las tarjetas comodín, su consulta original también podría ser:

qr = "Select Tbl_Country.* From Tbl_Country _
      WHERE id_Country LIKE [fid_country]"

A continuación, puede obtener valores comodín para fid_Country, como

qr = replace(qr,"[fid_country]","G*")

Una vez que haya terminado con eso, puede usar la cadena para abrir un conjunto de registros

set rs = currentDb.openRecordset(qr)
0
agregado

Si construyes tu consulta así:

PARAMETERS ParamA Text ( 255 );
SELECT t.id, t.topic_id
FROM SomeTable t
WHERE t.id Like IIf(IsNull([ParamA]),"*",[ParamA])

Todos los registros se seleccionarán si el parámetro no se completa.

0
agregado
¿Funcionará lo mismo para un GROUP BY opcional?
agregado el autor Chad, fuente
@Chad No estoy seguro de lo que quiere decir, quizás PARAMETERS ParamA Text (255); SELECCIONAR IIf (IsNull ([ParamA]), "*", [ParamA]) AS Expr1, t.id DESDE la tabla 1 AS t GRUPO POR IIf (IsNull ([ParamA]), "*", [ParamA]), t. id HAVING (((t.id) Me gusta IIf (IsNull ([ParamA]), "*", [ParamA])));
agregado el autor Fionnuala, fuente

No creo que puedas. ¿Cómo estás ejecutando la consulta?

Yo diría que si necesita una consulta que tenga tantas variables abiertas, colóquela en un módulo o clase de vba y llámela, dejándola construir la cadena cada vez.

0
agregado

Bueno, puede devolver valores que no sean nulos pasando * como el parámetro para los campos que no desea usar en el filtro actual. En Access 2003 (y posiblemente versiones anteriores y posteriores), si está utilizando como [paramName] como criterio para un campo numérico, de texto, fecha o booleano, un asterisco mostrará todos los registros (que coincide con los otros criterios que especifique). Si también desea devolver valores nulos, puede usar como [paramName] o Is Null como criterio para que devuelva todos los registros. (Esto funciona mejor si está creando la consulta en código. Si está utilizando una consulta existente y no desea devolver valores nulos cuando tiene un valor para el filtrado, esto no funcionará).

Si está filtrando un campo de Memo, tendrá que probar otro enfoque.

0
agregado

Tenga en cuenta que el comodín * con la palabra clave LIKE solo tendrá el efecto deseado en el modo de consulta ANSI-89.

Muchas personas asumen erróneamente que el carácter comodín en Access/Jet siempre es *. No tan. Jet tiene dos comodines:% en modo de consulta ANSI-92 y * en modo de consulta ANSI-89.

ADO siempre es ANSI-92 y DAO siempre es ANSI-89 pero la interfaz de acceso puede ser cualquiera.

Al usar la palabra clave LIKE en un objeto de base de datos (es decir, algo que persistirá en el archivo mdb), debe pensar: ¿qué pasaría si alguien utilizara esta base de datos utilizando un modo de consulta distinto del que usualmente uso? Digamos que quería restringir un campo de texto a caracteres numéricos solamente y había escrito su Regla de Validación de esta manera:

NOT LIKE "*[!0-9]*"

Si alguien involuntariamente (o no) se conectara a su .mdb a través de ADO, entonces la regla de validación anterior les permitiría agregar datos con caracteres no numéricos y su integridad de datos sería filmada. No está bien.

Mejor IMO para codificar siempre ambos modos de consulta ANSI. Quizás esto se logre mejor codificando explícitamente ambos modos, p.

NOT LIKE "*[!0-9]*" AND NOT LIKE "%[!0-9]%"

Pero con más participación en Jet SQL DML/DDL, esto puede ser muy difícil de lograr de manera concisa. Es por eso que recomiendo usar la palabra clave ALIKE, que usa el carácter comodín ANSI-92 Query Mode independientemente del modo de consulta, p.

NOT ALIKE "%[!0-9]%"

Tenga en cuenta que ALIKE no está documentado (y supongo que es por eso que mi publicación original se marcó abajo). He probado esto en Jet 3.51 (Access97), Jet 4.0 (Access2000 a 2003) y ACE (Access2007) y funciona bien. Anteriormente publiqué esto en los grupos de noticias y obtuve la aprobación de Access MVPs. Normalmente me mantendría alejado de las características no documentadas, pero hago una excepción en este caso porque Jet ha quedado obsoleto durante casi una década y el equipo de Access que lo mantiene vivo no parece interesado en hacer cambios profundos en los motores (¡o correcciones de errores! ), que tiene el efecto de hacer que el motor a reacción sea un producto muy estable.

Para obtener más detalles sobre los modos de consulta ANSI de Jet, consulte Acerca del modo de consulta ANSI SQL .

0
agregado
En realidad, el comodín también dependerá de la interfaz de datos que esté utilizando. En SQL ejecutado a través de ADO contra SQL Server, utiliza "%" en lugar de Jet SQL "*", por ejemplo.
agregado el autor David-W-Fenton, fuente
En realidad, Jet tiene dos comodines: "%" en el modo de consulta ANSI-92 y "*" en el modo de consulta ANSI-89. ADO siempre es ANSI-92, DAO siempre es ANSI-89 y la interfaz de acceso puede ser cualquiera. Puede que no lo sepa porque siempre usa DAO.
agregado el autor onedaywhen, fuente
@Air link ahora reparado.
agregado el autor onedaywhen, fuente
Gracias. Me estaba costando encontrar una URL actual que pareciera tener el contenido descrito, pero quizás no haya ninguna. No se puede encontrar mucha información sobre hasta qué punto esto es un problema en 2010 y versiones posteriores de Access, tampoco.
agregado el autor Air, fuente