2008-12-29 15 views
15

Tengo un MDB de acceso existente. Estoy agregando un botón de comando a un Formulario existente que ejecuta un informe existente. El cambio que se realiza es que este botón debe pasar un parámetro que contiene la ID del registro sobre el que se informa: actualmente el informe se ejecuta en cada registro en el MDB.¿Cómo paso un parámetro a un informe de acceso programáticamente?

He alterado la consulta en la que se ejecuta el informe para usar un parámetro para el valor de ID, de modo que ahora cuando se hace clic en el botón se accede a la ID del registro para informar y el informe se muestra como debería.

Sin embargo, no puedo entender cómo pasar un parámetro en el informe para que la consulta lo use. ¿Cómo puedo hacer esto?

método

Respuesta

20

El DoCmd.OpenReport tiene varios argumentos, uno de los cuales es una declaración Dónde:

DoCmd.OpenReport"rptReport", acViewPreview,,"ID=" & Me.ID 

Eso es

expression.OpenReport(ReportName, View, FilterName, WhereCondition, WindowMode, OpenArgs) 
+0

Creo que esta es la forma más limpia de hacerlo. –

+0

AHA! ¡Esto es lo que estaba buscando! Gracias, Remou. –

+0

Estoy usando Access 2003, y la propiedad "WhereCondition" es en realidad el 4º parámetro, por lo que solo necesita dos comas en el ejemplo anterior, a saber: DoCmd.OpenReport "rptReport", acViewPreview ,, "ID =" & Me .ID –

3

Mi enfoque general para este tipo de problema es salvar a los criterios en la base de datos, generalmente una tabla de control que tiene una fila. Luego, para hacer referencia a sus criterios, coloca una consulta en paranthesis que devuelve un valor de los criterios que desea. En su caso, sería algo así como:

(select reportID from control) 

La ventaja de esto es que techinque la tabla de control recuerda los ajustes para la próxima vez que se ejecuta el informe. Por supuesto, ReportID estaría vinculado a un campo en un formulario. También me gusta el hecho de que sus consultas estén aisladas de las formas; se pueden ejecutar independientemente de las formas.

+0

La mesa de control es una buena idea, gracias. – PaulDH

1

Por qué todos quieren que esto sea tan complicado, no lo sé.

  1. guarde la fuente de registros de su informe sin parámetros.

  2. según lo sugerido por Remou, pase los criterios en el argumento apropiado de DoCmd.OpenReport.

Tratar de hacerlo de otra manera va a ser una cuestión de resistencia a los métodos naturales para realizar tareas en Access.

2

La cláusula Where del docmd.openreport es una cadena que utiliza el mismo formato que la cláusula where en una instrucción SQL.

La razón para poner parametrizar su consulta en el docmd en lugar del RecordSource del informe es la flexibilidad. Es posible que tenga la necesidad de abrir el informe sin ningún parámetro/devolver todos los registros o tener la capacidad de filtrar en diferentes campos.

1

Sé que esta es una publicación anterior, pero esto me llevó un poco. El error fue "uso no válido de parren", pero el problema fue el espacio en el nombre del campo. Estaba creando un informe desde un DB que alguien cometió el error común: espacios.

Para pasar un parámetro a una consulta a través de la cláusula where cuando el campo de base de datos se utilice un espacio de este ejemplo:

DoCmd.OpenReport "rptByRegionalOffice", acViewPreview, , "[" & "Regional Office" & "]" & "=" & "'" & cmboOffices.Value & "'" 

Si se piensa en ello se puede ver que esto producirá where [Regional Office]='string value' igual que lo haría esperar en el acceso sql.

+3

Realiza muchísimas concatenaciones innecesarias. Todo lo que realmente necesita es: "[Oficina Regional] = '" & cmboOffices.Value & "'". Y tenga cuidado si [Oficina Regional] puede incluir el carácter "'". Es normal en Access utilizar comillas dobles para cadenas, por lo que: "[Oficina Regional] =" & Chr (34) & cmboOffices.Value & Chr (34) –

+3

Además, poner espacios en los nombres de los objetos (así como los caracteres no alfanuméricos)) es algo que deberías dejar de hacer. Como puede, muchas personas lo hacen, pero eso se debe a que no prestan atención al hecho de que el nombre del campo y su título se pueden establecer por separado, por lo que un campo RegionalOffice puede tener una propiedad de Título de "Oficina regional". Esto significa que cuando lo suelta en un formulario o informe, tendrá automáticamente el título adecuado para los humanos (con espacios), mientras que el nombre del campo es compatible con SQL (es decir, no requiere corchetes). –

Cuestiones relacionadas