Macro condición Where para Varios Formularios

No te había contestado hasta ahora porque, aunque estaba seguro de lo que me comentas no se podía hacer, he hecho un par de pruebas y he estado buscando información por Internet sobre el tema.
Efectivamente las macros son "individuales" (por decirlo de alguna manera) y no pueden funcionar con el Me, como apuntas. Sólo con código se puede hacer lo que comentas.
Supongo que lo sabrás, pero si no controlas mucho el tema de VBA puedes crear la macro y hay una opción en Access que es "convertir macros a código". De esta manera lo que "hace" la macro se convierte a VB y puedes retocar el código. En definitiva, creas y guardas la macro, la asignas al objeto (botón, combo, etc.) y la conviertes en código. Así, ese objeto quedará con un código en VBA asociado.
No sé si lo que te comento puede servirte de algo. Si sí te sirve, pues me alegra haber podido echar un cable.
Bueno. Si tienes alguna pregunta sobre el tema no dudes en contactar conmigo.
Ya me dirás.

Muchas gracias por tu ayuda. Tenía la esperanza de que hubiera algún método, ya que evitaría duplicar códigos continuamente.
El origen de la pregunta inicial es en parte el siguiente, si consideráis conveniente iniciar una nueva pregunta, por favor indicármelo.
El problema es que en una base generada hace unos 7 años, recientemente en una par de ocasiones ha dado problema de desvincular los módulos de VB. En este momento literalmente los ha borrado, pero en cambio las funciones realizadas con macros funcionan sin problema. Si intento Exportar un modulo de VB de back up anterior, e Importarlo en la Base actual con el problema lanza el mensajes: "El nombre de módulo 'Form_Ase_PoscliSolisPress_F' no es válido"
Y si intento importar un Formulario lanza los mensajes: "El nombre está en conflicto con el de un módulo, proyecto o biblioteca de objetos." y al aceptar lanza "No hay ningún registro activo"
Y si intento renombrar algún formulario (no les pasa a todos), al pulsar Enter vuelve al nombre inicial, sin ni siquiera indicar porqué no acepta en nuevo nombre.
He tenido que volver a un Back up y perder bastante trabajo, lo que me hacía querer convertir todo el VB a macros, pero para redondear, quería poder crear una sola macro que sirviera para abrir el Id de Cliente en que te encuentras, sin importar el formulario en el que te encuentres. Pero bueno, con mucha frecuencia uno de ha de adaptar a los programas, no los programas a uno ;)
Gracias

Ciertamente no acabo de ver por qué se te producen los errores que te saltan en la BD. Lo único que puedo hacer es ofrecerme a que, si quieres, me remitas esa BD (comprimida en zip o rar) y yo le echo un vistazo para ver si detecto "algo" raro, y, si sé cómo arreglarlo, pues intento solucionarlo. Sé que hay gente que no gusta de enviar sus BD con información a un extraño, por lo que si no lo consideras conveniente evidentemente me lo comentas y tan amigos.
Mi correo es [email protected]
Si me la envías te agradecería que en el correo me indicaras expresamente el nombre de uno o algunos de los módulos y formularios que te dan problemas.
También te agradecería que me dijeras si actualmente usas Access 2003 ó 2007.
Bueno. Estés de acuerdo o no espero noticias tuyas.

Muchísimas gracias por tu colaboración.
Se trabaja en Access 2007 pero con archivos MDB, no accdb. La verdad es que no tengo ni idea de que módulos pudieron generar el problema. La cuestión es que hay temporadas en las que solo se añaden datos, pero casi no se modifica (formularios, consulta, VB, macros, etc) y otras en las que en 30 minutos se retocan o generan muchos cambios. Y las 2 veces fue, cerrar la base, sin síntomas raros, y al abrirla dar un mensaje de conflicto con los códigos de VB y tener que recurrir al back up, porque los daños eran tan extremados, que no se podía perder más tiempo tratando de repara (bloqueando el trabajo diario del personal), era mejor perder los cambios y tratar de volver a aplicarlos con calma.
La base está compuesta por un MDB con todas las tablas, y otro Funcional (con todas las consulta, forms, VB, Macros, etc), no habría problema en enviarte la parte Funcional. Pero como comenté, la base arrastra 7 años (en manos de desarrolladores inexpertos), y forms, consulta, etc que tendrían que haber borrado, creo que sería mucho mejor hacer una limpieza a fondo, y entonces tu tendría una situación menos caótica, no quería que pierdas más tiempo del imprescindible.
Podrías recomendar alguna web donde se exponga bien lo "recomendable" para estructurar (campos, tablas, relaciones entre tablas, consultas, forms, etc) algo con lo asegurarse que independientemente de los conocimientos de bases, ¿se parte de unos buenos cimientos que eviten problemas al desarrollar una base?
Saludos

Ok. Te comento:
El primer libro de Access que leí se hacía la pregunta: "¿Por dónde empiezo a crear una base de datos?" Y la respuesta era: "Cogiendo papel y lápiz"
Y, con los años, te das cuenta de que eso es una verdad como un templo. A eso, junto con la idea general de que "la base de datos se debe adaptar a tus necesidades, y no tus necesidades a la base de datos" (sé que esto parece de perogrullo, pero es algo que se pierde de vista con facilidad cuando planeas hacer una BD), es la base para empezar a crear una nueva BD.
Hay información por Internet, pero está muy dispersa (y además no he sido capaz de encontrar un texto que cubra todas las posibilidades más "normales" de Access). Personalmente soy partidario de comprar algún libro de nivel básico o intermedio (según los conocimientos previos) para iniciarse o completar. De todas maneras te paso aquí un par de links, algunos de los cuales te llevarán a links con más información.
Access es un sistema de base de datos relacional. Como pienso que es importante entender este concepto para crear una buena BD (aunque sea un poco "duro" de leer) te recomiendo una visita a esta página: http://es.wikipedia.org/wiki/Base_de_datos_relacional
Para temas de cómo empezar a diseñar una base de datos Access échale un vistazo a este: http://support.microsoft.com/default.aspx?scid=kb%3BES-ES%3B289533
La búsqueda por Internet es útil (a veces) para temas muy concretos y muy delimitados.
Y, finalmente, como ya tienes mi mail, decirte que quedo a tu disposición para cualquier consulta que puedas tener sobre este u otro tema. No dudes en escribirme cuantas veces necesites, porque, si lo sé, te responderé, y si no lo sé, pues o bien intentaré buscar una solución o simplemente te digo que no lo sé ;)
Poca cosa más. Un gran saludo, y suerte!

Muchas gracias de nuevo por tu colaboración y gracias por los links. La verdad ya estudié manuales de Access (Básico, Medio y según ellos Avanzado.) Pero en ellos te explican como generar, relacionar, etc. Pero hablan de concepto, que según dice gente en webs, son importantes y otros recomendables para obtener un buen rendimiento. Por ejemplo:
Usar nombres cortos para: Campos, tablas, consultas, etc evitando símbolos o espacios (puede reducir tiempos de respuesta)
Tengo entendido, pero no confirmado, que es importante para la velocidad el orden de los campos dentro de una tabla (todos los de clave deberían ir primero, y los de datos simples después)
Supongo que el encadenar consultas (1ª recoge los datos de la tabla y genera algún por cálculos, etc, 2ª relaciona la 1ª consulta con otras tablas, 3º filtra y ordena la 2ª consulta) es negativo para la velocidad.
Para estos aspecto a veces la gente dice "haced pruebas", creo que no siempre se puede ir a base de prueba y ensayo, seguramente hay cosas 100% seguras. Creo que si fuera posible, sería genial que entre todos los que domináis de bases, se estableciera una lista de aspectos que hay que tener en cuenta al crear una base, podría ayudar a no cometer errores y ha evitar muchas consultas que puedan venir por una mala creación de la base.
Gracias por todo