Filtrar formulario e incluir resultados en un informe (botón)

Estoy haciendo una bd en access, pero no consigo que me muestre un informe para imprimir en función de los registros que tenga previamente filtrados en el formulario.

O me muestra 1 o me muestra todos,

No tengo claro como hacerlo, aunque he visto bastantes respuestas no doy con ello.

2 respuestas

Respuesta
1

En principio (y si los datos del informe tienen relación con los del informe) esto es: son coherentes, el filtro aplicado debería estar disponible en la propiedad 'Filter' del formulario.

Bastará abrir el informe enviándole el filtro como condición (la propiedad es: Me. Filter).

Inestimable Eduardo: NO pienses (te puedes hacer mucho daño)

Basta que en origen de datos del informe no figure uno de los datos utilizados en el formulario para filtrar: para que aparezca una inconsistencia de datos que los convierta en incoherentes.

Veo que es muy creativo el proponer una variable (a nivel de formulario) para utilizar en un solo modulo (¿sabes que existe  DIM a nivel de modulo?).
Lo curioso es que esa variable es copia aproximada (o alternativa) de la propiedad Filter del formulario.

Revisa la solución que has publicado y haz las cosa bien, que sobra la mitad para hacer lo mismo (y mejor).

(Temo que el final de tu posicionamiento va a ser que nos impongan silencio ... mejor así podrán arreglar los daños que provoco un indeseable al llenar el foro de SPAM por sufrir 'el síndrome del principito')

¡Gracias!

Funciona perfectamente!

Private Sub Comando534_Click()

DoCmd.OpenReport "T_MEDIOS_COBRO Consulta", acViewPreview, , Me.Filter


End Sub

Muy buena solución, sencilla (pare el que sabe y que bueno es saber) y que da muchas alternativas y solución al tratamiento de la información.

Gracias

David, me alegra que te funcione y con tu permiso añado una respuesta (será la ultima en este hilo).
-------------------------------------------
Eduardo, un poco de teoría:
Los módulos pueden estar asociados a un formulario/informe o pueden ser independientes, en ellos puede haber variedad de declaraciones tanto privadas como publicas he incluso constantes (publicas y privadas), depende del ámbito que necesiten abarcar.

No es la primera vez que un programador (serio) hace publico un evento de formulario para poder manipular datos desde una ubicación ajena al formulario (simplemente le cambio el ámbito).
La diferencia de un modulo asociado a un objeto informe/formulario con un modulo independiente esta en que al cerrar el formulario/informe ... desaparece la opción, las variables e incluso el objeto (los módulos independientes ni se abren ni se cierran: simplemente están).

No estoy de acuerdo con el planteamiento de que el usuario es ¿? Y ejecutará la acción 'abrir informe' aunque en el formulario que utiliza para filtrar ya no aparezcan resultados.

Tomado de la ayuda de Access (su particular biblia, porque supongo que la acción de abrir formulario no te la atribuirás como propia) ...

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)

Por otra parte:

La variable a nivel de procedimiento haría exactamente lo mismo que a nivel de modulo y liberaría antes los recursos consumidos pues desaparece con el 'End' (sub o Function)

Para filtrar el formulario -y poder utilizar la propiedad Count del RecordsetClone- hay que utilizar la propiedad Filter o dilapidar recursos generando un entorno paralelo (+ tiempo + recursos y similar resultado si se hace bien).
Siento curiosidad sobre como 'filtrar un conjunto de datos' sin utilizar los datos ¿por extrapolación?.

Respuesta

Lo mejor es definir una variable a nivel de módulo del formulario para almacenar en ésta el filtro y con base en este filtrar el formulario y filtrar el informe con la clausula Where. Observe este código que utilizo en el ejemplo de filtros avanzados que tengo en YouTube https://youtu.be/vnmVcfBwtIw

Private Sub btnImprimir_Click()
     If Me.RecordsetClone.RecordCount = 0 Then
        Exit Sub
     ElseIf Me.RecordsetClone.RecordCount > 0 And Len(sFiltro) > 0 Then
        DoCmd.OpenReport "rptEmpleados", acViewPreview, , sFiltro
     Else
       DoCmd.OpenReport "rptEmpleados", acViewPreview
     End If
End Sub

En este caso sFiltro está definido a nivel de módulo del formulario.

Option Compare Database
Option Explicit
Dim sFiltro As String

Es lógico los datos serán coherentes pero esta respuesta da mucho que pensar (y si los datos del informe tienen relación con los del informe) que redundancia.

Enrique observe que el usuario ha aplicado siguiendo el modelo del código que propuse en parte, pero como no le preocupa si el informe se abre sin datos etc., no incluyó la validación, entonces no es "paja", es hacer las cosas bien, por esto se requiere más código, pero bueno lo importante es que el usuario ha solucionado el inconveniente.

No obstante, lea bien "En este caso sFiltro está definido a nivel de módulo del formulario" y NO a nivel de módulo público. Ahora, usted como programador sabe que estas variables sirven para construir criterios complejos y a veces para el origen de datos del formulario o subformulario (algo muy importante en bases de datos de gran tamaño), es mejor que utilizar Me. Filter que debe cargarse toda la información para después filtrar.

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas