Access - Consultas con campos vacios, null, y rellenos.

Buenas,

tengo un problema.

Tengo un formulario que me muestra una serie de registros en funcion de una consulta.

En criterios de esa consulta, en el campo correspondiente, tengo puesto el criterio - Como "*" & [CAJA DE OPCIONES]" y hasta ahora me lo hacia todo bien. Es decir, me mostraba todos los registros si en una caja de opciones no marcaba nada y me mostraba los registros correspondientes dependiendo del valor escogido en la caja de opciones.

Lo que me pasa, es que ahora el campo al que hace referencia esa caja de opciones, ahora tiene campos Nulos, por lo tanto el "*" en los criterios ya no lo puedo usar.

Resumiendo, lo que quiero es que si no elijo nada en la caja de opciones me muestre todos los resultados Incluyendo los que están vacios o son null, y si marco alguna opcion de la caja de opciones que me muestre los registros correspondientes.

No se que poner en criterios.

Por cierto, el formulario posee varias cajas de opciones que hacen referencia a esa consulta, por si sirve de ayuda.

Un saludo y gracias

Access tiene una función (Nz) que devuelve un valor alternativo si detecta un valor de tipo NULL

Original:

Alternativa:

Para esta situación devuelve una cadena de texto vacía, pero puede devolver un cero si se espera un numero, o una fecha o una frase.

Lo siento, no me sale,

de hecho al ponerlo, una de dos... Solo me lo acepta si

- Pongo comillas antes del NZ y al final
- Cambio la coma despues del corchete por un punto y coma...

En criterios me queda algo asi:

"*" & Nz([Formularios]![INDEX]![CABEZAL];"")

O

"*" & "Nz([Formularios]![INDEX]![CABEZAL],"")"


Gracias

Me he basado en los datos publicados y en ellos no aparecen las dobles/simples comillas que definen a un dato como texto o (sin ellas) como numero o variable, de hecho solo hay una parte de la expresión sin pistas de cual es el separador decimal o de listas.

Utilizar como separador la coma simple o el punto y coma es una de las diferencias forzada por la configuración regional del sistema operativo de la maquina en que se ejecute.

En la versión castellana de Windows, la configuración regional impone que se utilice la coma simple como separador para los decimales (en otras configuraciones el marcador es el punto).

En esa misma versión, al utilizarse la coma como separador decimal, no se puede utilizar como separador de listas y se sustituye por el punto y coma.

Concluyendo: son 'peculiaridades' en la sintaxis impuestas por el idioma regional que tenga la maquina.:

En VBA ===>
La coma siempre será el separador de listas y el punto es el separador decimal.

Fuera de VBA ==>
El separador de listas y el separador decimal que utilice el sistema operativo en el que corre la aplicación.

Una vez aclarado el problema de sintaxis y utilizado el adecuado a esa expresión deduzco que ha funcionado.

Una acotación a esta expresión : "*" & "Nz([Formularios]![INDEX]![CABEZAL],"")"

Si el cuadro de texto 'cabezal' no llega a crearse (el caso de un formulario con origen pero sin datos) NZ dará error y no funcionara, se tendrá que utilizar una alternativa que simule a Nz.

Lo siento, quizas no me explique bien, pero no me sale.

En la expresion:

"*" & "Nz([Formularios]![INDEX]![CABEZAL],"")"

Puesta asi, no me muestra ningun resultado.

Y si la coloco asi:

"*" & Nz([Formularios]![INDEX]![CABEZAL];"")

Tampoco me muestra ningun resultado.

La unica manera de que me muestre resultados, aunque sin llegar a mostrarme los resultados nulos es la siguiente:

Como "*" & Nz([Formularios]![INDEX]![CABEZAL];"")

Has publicado una mínima parte de ese código y se desconoce donde y cuando se utiliza, para poder dar una respuesta que cumpla los requisitos hace falta ampliar información con (por ejemplo) La SQL de la consulta (si es parte de una consulta).

En principio, si lo que se desea es que se muestren los campos de tipo NULL con el resto (esto es : TODOS sin distinción) verificaría si eliminando la condición aparecen (pueden estar filtrados por causas ajenas) y si aparecen (los NULL son muy mala compañía) basta con eliminar el filtro (no nos valdría el asterisco porque al parecer no asume en esta ubicación los NULL)

No se debe confundir un NULL (para Access es un estado puntual, su valor es Empty = 'sin inicializar') con una cadena vacía o sin datos (el asterisco implica 'cualquier cosa que exista' y un empty aun no 'ha nacido').

Intentare ser mas concreto...

Esta es mi tabla principal



A la cual le aplico esta consulta...Con estos criterios



Y me arroja estos resultados (sin los registros cuyos valores en cabezal son "Null")



Si elimino criterios en la consulta, para que me muestre todos los registros



me los muestra correctamente, incluyendo los registros cuyos valores en "Cabezal" son "Null"




Y este es mi codigo SQL de la consulta con el criterio inicial puesto:

SELECT MAQUINAS.CABEZAL, MAQUINAS.CLIENTE
FROM MAQUINAS
GROUP BY MAQUINAS.CABEZAL, MAQUINAS.CLIENTE
HAVING (((MAQUINAS.CABEZAL) Like "*" & Nz([Formularios]![INDEX]![CABEZAL],"")));




Gracias.

Con la informacion actualizada se puede entender el anormal funcionamiento de esa consulta.
No es de selección es de datos agrupados y su comportamiento deja de ser anormal.

Si la consulta funciona y el problema es que presenta es ver TODOS los registros (nulos incluidos que siempre son problemáticos), propongo dividir la consulta en dos partes, lo que permitirá simular dos consultas, una con condiciones y otra sin ellas.

En función del dato en : Formularios]![INDEX]![CABEZAL] se aplica o no el filtro.


En la variable L_SQL tenemos un origen de datos que solo hay que asignárselo al objeto que lo mostrará (formulario, subformulario, cuadro de lista ...)
Quizás sea necesario algún retoque en la sintaxis, simular un entorno para verificar la sintaxis fuera del entorno real .....

Y esto deberia pegarlo en el codigo SQL de la propia consulta?

Porque me da error de que "se esperaba algun tipo de instruccion"

Gracias

El nuevo origen de datos (L_SQL) se crea en tiempo de ejecución y por lo tanto se ha de asignar también en tiempo de ejecución al formulario que muestra el resultado.

Pregunta:
¿Qué evento se utiliza para ejecutar la consulta?
El formulario que presenta los datos ¿esta abierto siempre, o se abre/cierra cada vez?
Por ultimo ¿el formulario se esta utilizando como subformulario de Index?

Asignar una SQL como origen de datos a un formulario se acostumbra a hacer así:

Forms.[nombre-del-formulario].RecordSource = L_SQL

En L_SQL esta la consulta original condicionada o no en función de [Cabezal].

- ¿Qué evento se utiliza para ejecutar la consulta?

La consulta se ejecuta despues de diferentes eventos de "despues de actualizar". En realidad la tabla original es mucho mas compleja, el ejemplo que os he puesto es una consulta muy basica, pero en realidad hay mas campos con criterios.

- El formulario que presenta los datos ¿esta abierto siempre, o se abre/cierra cada vez?

Siempre esta abierto.

- Por ultimo ¿el formulario se esta utilizando como subformulario de Index?

Efectivamente, El formulario donde muestro todos los datos, es un subformulario de INDEX.

En base a la ultima aclaración, para mostrar en su destino (el subformulario) el resultado de la selección, la sintaxis adecuada es:

Me.[nombre-del-formulario].FORM.RecordSource = L_SQL

Esto asignara la SQL (anterior consulta modificada) al subformulario.

Me hace dudar si todo este hilo ha servido para algo ya que el verdadero entorno es diferente (antes era una consulta problemática, si aumenta el numero de elementos que puedan ser problemáticos se puede complicar la solución).

Con información sesgada solo se pueden obtener medias o pobres soluciones.

Gracias a todos por vuestra ayuda,
pero he encontrado una solucion mucho mas sencilla que me vale.

Eliminando de la consulta el campo cabezal y creando una nueva "columna" que contenga esto:

CABEZAL_0: Iif(isnull([CABEZAL]);"";[CABEZAL])

luego en la celda del formulario le pongo como origen de datos ese "CABEZAL_0",.

Gracias por vuestra atencion igualmente.

Es una opción valida que tendrá la ventaja de que no interfiere con lo ya creado.

El problema no hubiera existido -ni existirá en un futuro- si en el diseño de la tabla se le niega al campo el valor NULL y se le adjudica un valor por defecto (una cadena vacía, un cero, la fecha de creación o .... ) algo que lo haga transparente y adecuado al tipo, necesidad.

Pruebe con la siguiente instrucción

Como "*" & [CAJA DE OPCIONES]" O EsNulo([CAJA DE OPCIONES])

Lo siento,

siguen sin aparecerme en los resultados las entradas con valores nulos...

Eduardo, con esta instruccion:

Como "*" & [CAJA DE OPCIONES]" O EsNulo([CAJA DE OPCIONES])

Veo comillas de cierre pero no de apertura..

He probado diferentes combinaciones (quitadno esas comillas por ejemplo) y me siguen sin aparecer los registros con celdas nulas...

Estuve analizando y no es posible hacer la consulta desde la cuadricula con las 2 condiciones, se debe hacer mediante código y SQL. No obstante, ¿para qué agrupa por cliente?, si todos son diferentes.

No obstante, puede utilizar desde el formulario INDEX un procedimiento haciendo los ajustes minimos

Por ejemplo, si en el formulario INDEX ingreso LUA, obtengo:




Ahora, si no ingreso nada y doy Enter obtengo:

He intentado pegar el codigo "tal cual" en el SQL de la consulta y me devuelve un error de que se esperaba "algun tipo de instruccion".

¿Es ahi donde lo tengo que colocar?

Gracias.

¿Puede adjuntar una imagen? Es necesario saber desde donde se llama la consulta

Gracias a todos por vuestra ayuda,
pero he encontrado una solucion mucho mas sencilla que me vale.

Eliminando de la consulta el campo cabezal y creando una nueva "columna" que contenga esto:

CABEZAL_0: Iif(isnull([CABEZAL]);"";[CABEZAL])

luego en la celda del formulario le pongo como origen de datos ese "CABEZAL_0",.

Gracias por vuestra atencion igualmente.