Access - filtro informe basado en consulta de unión

Hola a todos:
Llevaba tiempo peleando con la forma de hacer una consulta de 2 tablas, después de probar muchas select y diferentes formas de relacionarlas, me acordé de las consultas de unión, haciendo una conseguí lo que quería, ahora se me plantea la duda de como pasarle un filtro a ese informe, en su evento al abrir tengo:
Private Sub Report_Open(Cancel As Integer)
Dim filtro As String
'filtro = "producto_muestra=2 and producto_muestra_v=2"->viene de una consulta de union, se queda con el primer nombre de campo, no los dos
filtro = "producto_muestra=2"
Me.Filter = filtro
Me.FilterOn = True
End Sub
Tal y como está ahora mismo me filtra correctamente por el producto 2, como puedo hacer que me pregunte por qué producto voy a filtrar.
Se me acaba de ocurrir que en el evento open abra un formulario en el que pregunto el codigo filtro.
Voy hacerlo y os cuento.
Pablo

Pues no consigo hacerlo. Hice un formulario modal y emergente que me pregunta el código para filtrar, pero no se pasarselo al informe, alguien puede echarme una mano.
Gracias
Pablo

¿Hay algún producto que cumpla a la vez ambas condiciones?

Si el producto ha de cumplir ambas condiciones, se aúnan con AND, si es suficiente con una (la otra e incluso ambas) se utiliza OR.

Hay diferentes formas de que un informe obtenga un dato para su uso interno:

.- Enviar el dato en la llamada al informe (desde VBA y en la llamada hay dos opciones para filtros y una tercera de uso libre)
.- Enviar el dato como un parámetro (en el informe aparecerá en la variable/propiedad 'OpenArgs' (la opción libre')
.- Dejar abierto el formulario que solicita el dato y (en el informe) hacer referencia al formulario que lo tiene y desde el que normalmente se le llamará.
.- Se admite que en el evento Open del informe se solicite el dato con un ImputBox (y aplicarlo como parámetro para el filtro).

En el informe no se precisa crear una variable para después copila en la propiedad FILTER del informe, se le puede asignar directamente a la propiedad y (cuando se desee aplicar) simplemente se activa con FilterOn (si no se activa ...a efectos prácticos no existe).

Un formulario modal acostumbra a aplicar la exclusividad (no es la mejor de las opciones) aconsejaría que se le activase la de emergente y en cuanto finalizase su trabajo lo ideal es cerrarlo.

Hola
Como decía al principio, este problema surge al añadir una tabla más, la muestras_v, con tabla muestras tenía el asunto solucionado, preguntaba en un formulario el código de producto y tenía 3 opciones de orden, al aceptar pintaba un informe1, como esta opción me parece mejor, voy a cambiar el informe1 por el resultante con la nueva consulta.
Gracias
Pablo

Pablo: ¿podías darme algún dato más sobre la consulta de unión?

Para poder formalizar con éxito una consulta de unión, los datos (el número de campos) ha se ser el mismo y su tipo compatible.
Se puede aceptar crear elementos neutros para sustituir campos que no existe en alguna consulta (y lograr la de unión).

Un clásico de esta posible necesidad podría darse al intentar unir resultados de ventas de diferentes sucursales de la misma empresa, en la que una de sus sucursales tiene un campo más (pongamos que una sección más) que se desease mantener.
Para poder mantenerlos y generar la consulta de unión, a los conjuntos de registros que no tengan asociado el dato extra, se le crea uno fantasma (que puede ser una cadena vacía), no tiene valor: pero existe.

Si dos campos son compatibles en su tipo de dato (y su aplicación real) pero su nombre es diferente, se le puede modificar el nombre y sea en francés, alemán o sueco, redenominarlo al idioma que nos apetezca.

Por eso me llama la atención lo de 'producto muestra' y 'producto_muestra_v' para lo que supongo es el mismo dato, pero de diferente origen.

Si lo que cambia es el origen (y se desea mantener) se debería añadir 'origen' (el campo fantasma) como un elemento más y con el obtener su procedencia.

Puede utilizar una variable publica para asignarla en el formulario con eso puede utilizarla en el filtro del informe

muestras.producto_muestra y muestras_v.producto_muestra_v son campos numéricos de distindas tablas, las que uno. La consulta de union me da los datos que necesito, lo que estoy peleando ahora es filtrar los datos de ambas tablas, para ello, en un formulario pregunto la referencia a filtrar y tengo también 3 opciones de orden. Creo un filter="codigo_producto=" & CC.Column(0) & "" y cuando abro el informe lo leo y según la opcion_orden seleccionada creo un orden u otro.
Creo que está claro lo que quiero hacer, no?
Pablo

Lanzo el informe desde el formulario en el que pido datos con:
DoCmd.OpenReport "muestras_union_muestras_v", acViewPreview, "producto_muestra=" & Me.Cuadro_combinado12.Column(2) _
& " and producto_muestra_v=" & Me.Cuadro_combinado12.Column(2) & ""
Probé la opción filtro en la ventana inmediato y está bien: producto_muestra=2 and producto_muestra_v=2
Habrá que poner algo de me.filter= a qué y también me.filteron=true
pondría algo asi en el evento open?
Gracias
Pablo

No logro concretar de donde salen dos campos que al generar la consulta de union deberian deberian formar un unico conjunto con un unico nombre.
En el pirmer post publicas un filtro y un comentario asociado:

... 'filtro = "producto_muestra=2 and producto_muestra_v=2"->viene de una consulta de union, se queda con el primer nombre de campo, no los dos

Me quedo con la parte que crea confusión:
.... se queda con el primer nombre de campo, no los dos ....

Es lo correcto, la unión de dos consultas tomara un único nombre para el campo que une los dos subconjuntos y el filtro lo aplica a ese campo, que conserve el nombre del campo de la primera tabla es irrelevante.
Para verlo mas claro, basta con aplicar en las consultas originales un alias a los campos a unir (el mismo alias en ambas tablas), el nuevo campo tomara como nombre el alias, algo como:

Select ABC, BBC, producto_muestra As MUESTRAS From tabla1
Union
Select ABC, BBC, producto_muestra_v As MUESTRAS From tabla2
Where Muestras = 2
Order by ABC, MUESTRAS;

Si publicas la SQL de la consulta confirmarías mi sospecha o me harían ver mi error de planteamiento.

El metodo que empleas para abrir el informe no es el correcto, la sintaxis es:

El método OpenReport lleva a cabo la acción OpenReport (AbrirInforme) en Visual Basic.
Sintaxis

expresión.OpenReport(ReportName, View, FilterName, WhereCondition, WindowMode, OpenArgs)

Actualmente se aplica:

Deberia aplicarse así (la condición no debe de ir en FilterName, debe de ir en WhereCondition), hay que añadir una coma para que salte la posición del parámetro:

Al filtrar en la llamada, el informe cargara en su propiedad 'Me.Filter' la condición (y activara el filtro si es correcta la sintaxis).

Hola. Dices: …la condición debería ir en la cláusula where no en filtre… Ahora no puedo probarlo, por la tarde lo haré, seguro que funciona, entones la cláusula filtre como se utiliza?
Haciendo pruebas en la consulta de unión comprobé que, para obtener los datos que quiero, tenia que a acabar las 2 sql que uno con la cláusula where
Un saludo
Pablo

Las diferencias las impone el creador de la aplicación:

De 'FilterName' dice: Es un parámetro 'Opcional', su tipo es 'Variant', Expresión de cadena que es el nombre válido de una consulta de la base de datos activa.
Define consulta así:
(consulta: pregunta sobre los datos almacenados en las tablas o solicitud para llevar a cabo una acción en los datos. Una consulta puede unir los datos de varias tablas para que sirvan como origen de datos para un formulario o informe.)
Mi Conclusión: Si se da como dato el nombre de una consulta, la asigna como origen de datos del informe.


De 'WhereCondition' dice: Es un parámetro 'Opcional', su tipo es 'Variant', Expresión de cadena que es una cláusula WHERE de SQL válida sin la palabra WHERE.
Define Where así:
(cláusula WHERE: parte de una instrucción SQL que especifica qué registros se deben recuperar.)
Mi Conclusión: aplica una condición a los datos del informe que se abre.

La forma de utilizar cualquier parámetro de los opcionales es definirlos por su nombre o por posición, en este caso (la posición) debe de respetar los no utilizados (que quedarían en blanco, pero se mantiene la coma de separación) hasta que se llega al último de los que se utilizan, por ello lo de 'respetar la coma' para que asigne la condición donde corresponde.

Ayer me pedias la sql de la consulta, ahí va:
select codigo_muestra, muestreo_muestra, producto_muestra, marca_muestra,unidades_muestra,precio_muestra,pack_muestra,unidad_muestra
from muestras
UNION
select codigo_muestra_v,muestreo_muestra_v,producto_muestra_v, marca_muestra_v,unidades_muestra_v,precio_muestra_v,pack_muestra_v,unidad_muestra_v
from muestras_v;
Ayer confirmé que para obtener los datos que quiero tengo que acabar las dos select con Where producto_muestra=2 la primera y Where producto_muestra_v=2
que es similar a filtro=producto_muestra=2 and producto_muestra_v=2
Selecciono el dato de código de producto desde un formulario "listar_muestras", también selecciono el orden: Fecha, Precio, Precio/Unidad
Qué es mejor: variar la sql del informe o aplicar un filtro al idem? ( cosa que no consigo hacer)
La opcion orden cómo la paso?
Un saludo y gracias
Pablo

La consulta es correcta y la utilizare como referente.

Por la sintaxis no parece creada con el generador de consultas, así que para que veas lo que devuelve (número y nombre de campos), si no está guardada como consulta: créala pegando la SQL en una nueva consulta (en su 'vista SQL')

Ya creada utilízala para genera otra nueva, en ella apreciaras que solo hay un único campo (no existen referencias a los que finalizan con '_v' porque utiliza los nombres de la primera).

Si bajas todos los campos y aplicas la condición en el campo que corresponda, ¿al ejecutarla que obtienes?

Como es un conjunto único, se filtra por un único campo (no por dos pues ya son uno)

A las consultas individuales se les puede aplicar filtros (filtros que pueden ser totalmente independientes), para aplicar el filtro común, se le aplica al resultado de la unión y ese es el filtro que se utilizara al abrirlo en el Where del informe.

Los informes ... los informes NO son formularios, las reglas cambian, a los informes hay que mandarles datos sin ordenar (no hacen caso a los órdenes 'extranjeros' ya que ellos tienen sus propias herramientas).

Si se le quiere pasar un orden una opción es utilizar el ultimo parámetro OpenArgs (no olvidar lo de mantener las comas) aplicando la misma metodología que con la condición, esto es: 'el order by` sin el 'order by' (se puede generar en la consulta y copiar la sintaxis, tanto del Where como el Order by).
Otra alternativa es sustituir a OpenArgs por un dato al que se pueda acceder en tiempo de ejecución del informe.

Ya en el informe en su evento Open se le asigna al informe el orden deseado (pero ha de ser a los campos disponibles, habría que añadir: Fecha, Precio, Precio/Unidad .....
(que no existen en el actual origen de datos para el informe).

En el ejemplo voy a filtrar por un campo de un imaginario formulario y un campo de los existentes en orden descendente

En el informe:


No sé si lo he simplificado o complicado, pero Access tiene su propia personalidad y hay que someterse a ella.