Reporte filtrado a través de un combo
Quería ver si me ayudáis que no encuentro el error a la búsqueda de este informe.
Tengo un informe de existencias de almacén y a través de un combo en el formulario principal quiero seleccionar el stock de un almacén concreto.
Este es el informe
Este el formulario
El cual en el evento lleva
Private Sub CboAlmacen_Click()
DoCmd.OpenReport "RStockAlmacen", acViewPreview
End Sub
Y la consulta asociada al informe lleva
Pero al ejecutar en el combo me sale el reporte vacío, y no el almacén que busco.
En que me equivoco.
3 respuestas
En el evento Después de actualizar del combinado( al que para el ejemplo llamaremos Elegir) crea un procedimiento de evento y entre Private Sub y End Sub escribe
docmd.openreport"RstockAlmacen",acpreview,,"Almacen='" & me.elegir & "'"
Cuando quieras que te lo imprima directamente basta con borrar lo de Acpreview
Lo último es apostrofe comillas & y "cierra" & comillas apostrofe comillas
Sale el informe vacío
Habría que saber e diseño del informe. Mira, si tengo un formulario, no hagas caso al diseño, es sólo para que veas, que yo llamo Categorías a lo que tu llamarías Almacén 1, Almacén 2, etc. Y también tengo un combinado llamado Elegir, donde voy a seleccionar la categoría( en tu caso Almacén...)
Si ahora, en el combinado elijo una Categoría
Automáticamente me abre el informe sólo con esa categoría elegida
Por eso me extraña que te salga en blanco. Podría ser porque el combinado tenga dos columnas y en la que aparece lo de almacén1, Almacén 2, no sea la dependiente. En ese caso en la instrucción tendrías que hacer referencia al número de columna en que aparecen, teniendo en cuenta que en código VB, la primera columna es 0
De todas formas, como creo que tienes mi correo, y si no, es [email protected]
Mándame un mensaje y te envión un ejemplo. Si lo haces, en el asunto del mensaje pon tu alias Kokku, ya que si no sé quien me escribe ni los abro.
El Evento que yo usaría es el AfterUpdate del Combo.
Private Sub CboAlmacen_AfterUpdate()
DoCmd.OpenReport "RStockAlmacen", acViewPreview
End Sub
Si no resuelve tu problema comentamos. JTJ
me sale esto , el informe vacío
Revisa el "Criterio" que tienes en la Consulta.
Lo mejor es que lo establezcas con el "Asistente". Te sitúas en esa Fila >> Pulsa >> Diseño.
Elige >> Generador. Te saldrá un Formulario. A partir de ahí eliges el objeto bajo el que quieres filtrar.
Quizá te sobra la última parte de ! Almacen, puesto que es el valor que "ya" estás eligiendo en el ComboBox. Ya comentarás. JTJ
Personalmente soy más partidario de Filtrar en Formulario, y así la Consulta se puede usar para otros menesteres, pero eso es una cuestión de costumbres.
Si tienes el Origen de datos del Informe establecido, yo quitaría el criterio y lo haría así:
Si en tu Almacen es un Número y el Combo tiene como primera columna un Número
DoCmd.OpenReport "RStockAlmacen", acPreview, , "[Almacen]=" & Me![CboAlmacen]
Si tiene un Texto
DoCmd.OpenReport "RStockAlmacen", acPreview, , "[Almacen]='" & Me![CboAlmacen] & "'"
Saludos >> JTJ
Revise la expresión Forms! Principal. CboAlmacen parece que le sobra ! Almacen, si el origen de datos del cuadro combinado tiene un solo campo tipo texto, pero si el origen tiene por ejemplo, idalmacen y NombreAlmacen y el valor dependiente es la segunda columna, la instrucción del criterio quedaría Forms! Principal. CboAlmacen. Column(1),.
Filtrar en la consulta es más rápido que hacer el filtro en Docmd.OpenReport "reporte",acViewPreview,,"Almacen=" & CboAlmacen porque se debe cargar toda la información y esto repercute en bases de datos con bastante información.
Si, es verdad , sobraba ! Almacén
Esta perfecto!!
Comentas que filtrar en consulta es más rápido, aunque hay varias opiniones muy respetables. Por curiosidad, esto es lo que debería poner en la consulta:
"RStockAlmacen",acViewPreview,,"Almacen=" & CboAlmacen
Permítame le aclaro porque es más rápido crear un reporte con base en una consulta. Utilizo PostgreSQL como Back End y tengo tablas con mas de 1.000.000 de registros, imagínese si para un reporte tomo como origen de datos una consulta sin "filtrar", Access tendría que cargar el millón de registros y filtrar cuando se mande a imprimir, por ejemplo, 1 solo cliente. ¿Se justifica cargar toda el contenido de la tabla para un solo registro?
En el caso de PostgreSQL la consunta se hace en el servidor y no en Access lo cual es supremamente ágil, en Access las llamamos consultas "Específicas de SQL" Paso a través. Asimismo, por eso no soy partidario del uso excesivo de Dcount(), Dmax(), Dlookup() etc, porque son más rápidas las consultas SQL y además, no sirven para nada en bases de datos cliente servidor. Esto no lo digo yo, lo dicen quienes se conectan mediante ODBC con Access desde MySQL, DBmaria, SQL Server y PostgreSQL. Esta aclaración la hago con fin de ilustrar y no de ofender a otros, respeto los demás criterios.