Access - Ejecutar módulo/macro

Buenos días;

Os realizo la siguiente duda que tengo con mi BBDD y que, por mucho que busco en foros (Incluido este) no consigo encontrar la solución.
Os indico lo que me quiero realizar:

- Crear una macro que permita ejecutar un módulo.

- Crear un módulo que permita ejecutar una macro.

Hay que tener en cuenta que tanto la macro como el módulo contienen información (El primero crea y añade registros y el segundo los copia a otra tabla) y que deben de funcionar ambos.

El funcionamiento ideal sería que creará y añadiera el registro y después, al guardar, se copie la tabla donde se ubica a otra tabla (Esta última parte la tengo ya solucionada).

Espero que me puedan ayudar. Cualquier duda que os pueda surgir comentarlo.

Gracias.
Un cordial saludo.

Buenas tardes,

Ya he encontrado la solución al problema...

Muchas gracias a todos!!!

Hola Sandro, nos la puedes compartir?

Buenos días Xve,

Por supuesto que te puedo dar el código empleado. Te pido disculpas por el retraso, pero he estado realizando una muestra en Access de como funciona el código.

El método que he empleado es el siguiente: Cuando creo y añado un nuevo registro, esté se duplique a dos tablas. Creo que incluso este método se podría emplear en otros elementos, pero no he podido confirmarlo.

Para crear este formulario, previamente tenéis que crear dos tablas (Original y la copia), los formularios que queráis (En mi caso tres) y la macro.

Os explico brevemente. Al abrir el ejemplo, se muestra un formulario tipo "Varios elementos", donde nos muestra las oficinas. Si pinchamos en cualquiera de dichas oficinas, se abre un formulario tipo "Formulario" donde nos muestra los datos de cada oficina.

Ahora, si pinchamos en "Nuevo Registro" nos mostrará un nuevo formulario tipo "Formulario" en blanco. Es aquí donde añadiremos las nuevas oficinas que vayamos teniendo en la empresa. Y es aquí cuando se efectúa la "magia".

El botón "Guardar" del formulario ejecuta un código VBA. Dicho código esta dividido en dos partes:

- Primera parte: Ejecuta una macro.
- Segunda parte: Ejecuta el código de copia a dos tablas.

La primera parte, la macro, ejecuta un código que, en resumen, busca la tabla y guarda el nuevo valor. Si la abrís podéis ver y copiar dicho código.

La segunda parte efectúa lo siguiente:

- DoCmd.SetWarnings False --> Elimina la advertencia de "Sobrescribir", sobrescribiendo siempre.
- DoCmd.CopyObject , "Copia_Oficinas", acTable, "Oficinas" --> Efectúa la copia. El resumen del código es "Destino", AcTable, ]"Origen".

Tener en cuenta que el "Destino" es la copia de la tabla y que el "Origen" es la tabla donde se guarda el registro. Una vez que le damos a "Guardar", se ejecutará el código, copiando los datos en ambas tablas.

OJO!!!! NUNCA TENGAIS ABIERTAS LAS TABLAS, PORQUE SI NO EL CÓDIGO FALLARÁ.

Creo que es bastante sencillo y creo que me he explicado correctamente, no obstante si alguno tiene dudas que me lo diga.

Gracias y un cordial saludo.

• Copia-a-dos-tablas.zip(125,7 KB)

Me alegro que compartas tu forma de abordarlo.

La verdad es que me gusta ver cómo lo haría yo y como lo hacen los demás.

Siempre hay varias formas de obtener el resultado.

Como dice el refrán... "Todos los caminos conducen a Roma"

El 'lio' que se monta por no añadir un campo a la tabla 'oficinas' que las distinga ....

Y asi evitar esa multiplicidad de tablas (y demás), cuando con una simple consulta sobre la tabla (filtrando por oficina) obtenemos con una única tabla los mismos resultados.

Buenas Anonimo;

Lo primero, si tengo tantas tablas es porque en mi empresa, al contener muchos clientes, necesito diferenciarlos en varias tablas, con lo cual la consulta por oficina no valdría en este caso.

Lo segundo, la duda que me surgió es como consultar los datos contenidos en dos o tres tablas desde un mismo formulario y la idea que me surgió ha sido esta.

No obstante, si conoces una forma mejor, te pido por favor que nos la indiques.

Muchas gracias.
Un cordial saludo.

Si la gran cantidad de clientes están (con tablas múltiples) todos en la misma base, ocuparan exactamente lo mismo 'agrupados' en la misma tabla (el volumen es el mismo o incluso inferior), la conclusión para este caso es que la cantidad no es un problema.

En base a la necesidad expuesta de precisar 'combinar' varias tablas para trabajar con conjuntos, si todos los datos están en una misma tabla (con uno o mas campos que los diferencien ejemplo: oficina) bastaría filtrarlos por esos datos que los diferencian (sigamos suponiendo que: oficina) para obtener con menos esfuerzo el mismo conjunto de datos que antes.

Esa funcionalidad (filtrar en este caso) es para lo que se utilizan las consultas y esa consulta seria un origen valido para el mismo formulario anterior, con la ventaja añadida que su manipulación seria un poco mas coherente.

Y todo ello desconociendo las peculiaridades de esa aplicación, solo en base a la necesidad planteada y una mas de sus posibles alternativas.

Buenas tardes Anonimo;

En mi empresa tengo las tablas divididas en servicios (Por ejemplo: Mecánica, Informática, Recursos y Logística). Entiendo tu razonamiento de agrupar en la misma tabla todos estos servicios, pero luego a la hora de realizar una búsqueda solo por tipo de servicio sería más complicado, incluso teniendo filtros aplicados.

Y no solo tengo servicios, también tengo tablas divididas en instalaciones, bajas y demás. Tablas, que, aunque totalmente lógico, no pueden ser agrupadas debido a la necesidad continua de revisarlas de manera individual.

Y con esto tengo que decirte que me ha parecido totalmente lógico y razonado tu organización, pero como ves, en mi caso es algo más complicado.

Muchas gracias.

Supongo que a estas alturas y con la aplicación trabajando, algunos cambios (por ventajosos que puedan ser) pueden ser traumáticos.

Y dicho esto, el planteamiento es el siguiente:
¿Qué es mas idóneo?

1.- Un almacén distribuido en pequeños fragmentos

2.- Un único almacén bien organizado.

(no es una pregunta trampa, es el planteamiento que hay que hacerse en función de los medios disponibles)

Cada método tiene ventajas e inconvenientes (si hubiera un método eficaz al ciento por ciento para todos los casos: solo existiría ese ¿Quién querría un método comparativamente malo?

Buenos días Anonimo;

Obviamente lo más idóneo es la opción número dos, ya que cuanto mejor organizado esté más rápido y más fácil será acceder a los contenidos.

También es obvio que, teniendo la aplicación terminada, sea tedioso realizar mejoras. Pero eso es lo que estoy haciendo, realizando mejoras para subsanar los posibles errores que haya cometido al inicio, ya que está base de datos la he creado desde cero y sin conocimientos previos.

Ahora te realizo una pregunta... ¿Cómo podría realizar una mejora, en la que, junte en una misma tabla todos los servicios pero se puedan consultar de manera individual, bien en el mismo formulario o en formularios separados?

Como te comenté, tengo cuatro servicios que actualmente están separados tanto en tablas como formularios.

Gracias.

Con tan escaso conocimiento del entorno real, todo lo que pueda plantear no pasa de ser simple teoría.....

La forma de 'aunar' en una tabla un conjunto de tablas dispersas, consiste en analizar las tablas para aunar campos comunes y conocidos los diferenciales, ver como poder integrarlos (se carece de información para continuar ...)

Una vez resuelto el paso anterior, se añadiría un campo mas a cada tabla que seria su 'diferenciador' (podría ser 'Sección' y numérico para generar 'zonas dentro del conjunto' o bien mantener el titulo de la tabla (para trabajar en un entorno de ceros y unos, prefiero los números sobre las letras ya que son 'mas precisos')

Ya con las tablas compatibles el aunarlas en una sola no precisa explicación y para obtener datos para cada formulario (en un intento de reutilizar lo que se posee) basta tener este nuevo campo en cuenta y añadirlo a la SQL (u origen de datos de la consulta), donde antes había un 'Select * from mecánica ....' (que es el equivalente a utilizar el nombre de la tabla) habrá un 'Select * from Almacen Where Zona = Mecanica'

Y en un futuro lo de '... = Mecanica' se sustituye por una variable

Crear una 'nueva zona' seria tan elementalmente sencillo como poner un nuevo (y diferente) ID o titulo en ese 'campo extra diferenciador' sin necesidad de crear (mas bien duplicar) una tabla mas.

Avanzando en la programación, posiblemente muchos de los actuales formularios podrían seguir el mismo camino (integrarse) y para facilitar las diferencias entraría en juego una nueva (única) tabla mas que tendría (por ejemplo) el ID de zona (relación con la tabla anterior) el titulo y los títulos que se utilizarían (a modo de traductor) para los títulos de los formularios.

Esto es:
Seleccionada una zona (al abrir el formulario) se tomaría la referencia y se le cambiarían los títulos (o peculiaridades, puede ser incluso el color) según la zona, datos que estarían en la nueva 'tabla zonas'

Medítalo con calma y veras que mundo se abre ante esta posibilidad y también analiza la cantidad de 'paja' que se elimina, la mejora en el mantenimiento y la reducción de peso (lo que implica agilidad).

Buenos días Anonimo,

Muchas gracias por tu explicación tan detallada y siento no poder ofrecerte muchos detalles, pero por políticas de privacidad tengo que inventarme cuando os expongo una duda.

He estado pensando en como "Aunar" todo y se me ha ocurrido una idea que no se si será viable.

Crear una tabla que contenga todos los servicios (Por ejemplo: Mecánica, Informática, Motor y Recursos) diferenciados por un denominador que será SERVICIO (El resto de campos son iguales).

Luego, crear un formulario que contenga un objeto Control de Pestaña, en donde cada pestaña sería un servicio y donde te muestre los datos de ese servicio en concreto, es decir, si tengo una pestaña MECÁNICA solo me muestre los datos de ese servicio en concreto. Quizás sea una locura

Creo que de esta forma se agiliza el acceso a los datos y reduciría las 10 tablas y formularios a una sola tabla y un solo formulario. Y obviamente, sería mucho más sencillo el implementar un cuadro de búsqueda.

Espero que me puedas ayudar.

Gracias por toda tu paciencia y disculpa mi ignorancia.

Me tomare la licencia de transcribir mi primera intervención:

.....
El 'lio' que se monta por no añadir un campo a la tabla 'oficinas' que las distinga ....

Y asi evitar esa multiplicidad de tablas (y demás), cuando con una simple consulta sobre la tabla (filtrando por oficina) obtenemos con una única tabla los mismos resultados.
.....

Creo que al final has captado el concepto y SÍ, se puede aplicar a un grupo de pestañas (incluso en cada pestaña se 'copia' el formulario al que sustituye reutilizándolo)

Pero eso no creo que sea lo optimo, pues el mantenimiento sigue siendo el mismo, si analizas los formularios en búsqueda de los 'puntos comunes' para poder llegar a un único formulario, se tendría la ventaja de que la adaptación del usuario al puesto de trabajo (la curva de aprendizaje) seria muy pequeña y el cambio de lo que llamas 'Servicio' y que yo he denominado en algunos casos como 'Oficina' y en otros 'Zona' se puede hacer con un simple Cuadro combinado.

En un futuro mas o menos próximo (dependerá de como te adaptes a los nuevos conceptos y tu apertura a nuevas ideas) podría tener cabida la existencia de una tabla auxiliar que 'personalizara' la presentación (estética y/o ergonomía) de cada Servicio.

Por cierto y con respecto a la privacidad:

El nombre de tus clientes, direcciones etc, se pueden sustituir por un 'Juan Español', 'Pedro el Vasco' o 'Luis el madrileño' (no se atenta contra la privacidad) y el resto .... en fin tomas 'prestado' lo que otros han creado

Por mi parte me es tan indiferente el que trabajes con bicicletas como que trabajes con helicópteros, pero si es el caso no pongas en tus ejemplos que es alimentación o medicina (las manipulaciones e interacciones son diferentes) y solo servirían para crear confusión.

Buenas tardes Anonimo;

Entiendo que crear un formulario con pestañas no sería lo óptimo, pero la idea propuesta en la que tenga un único formulario donde cada servicio se distinga mediante un cuadro combinado no es una solución viable, ya que por fuerza necesito diferenciar los servicios en diferentes ventanas, pestañas o lo que sea.

Y ahora te pregunto, ¿Como se realiza una tabla auxiliar con los servicios? Desconozco ese método y no comprendo como esa opción podría ayudar a diferenciar los diferentes servicios.

Gracias.

El cuadro combinado 'no distingue al servicio', simplemente se utilizaría para cambiar (en el formulario) el servicio que se muestra, esto es, si cambiamos el ítem seleccionado, se modificaría el filtro que selecciona al servicio (en tiempo de ejecución) y presentaría sus datos.

La tabla auxiliar con los servicios .... no es en si misma 'un método', es simple creatividad

Pero si en una tabla tenemos el ID que representa a un servicio y a los campos de ese registro (cada campo para una propiedad) le indicamos cual es el color de fondo, o el de los títulos o el tamaño de la letra o ...(aquí entra la creatividad), al cambiar de servicio se le aplicarían esas propiedades y (jugando con lo que aportas)

Se modifica el titulo (mecánica, recursos, logística ....)
Se modifica el color de fondo
El tamaño de la letra
Se ocultan o muestran campos a utilizar (pues no todos los servicios necesitaran todos)
Se modifica la posición espacial de los objetos .....


En fin, todo ello guardado en una tabla que es fácil de manipular y que de forma transparente (al usuario) le cambia el entorno

Incluso se podría llegar al punto que se le permitiera al usuario cambiarlos 'a su gusto' y guardar la selección (Entra Pepe y el entorno es verde, entra Juan y el entorno es amarillo, entra Luis y su entorno es ... pues blanco y negro ya que su vista así lo requiere).

Buenos días Anonimo;

Muchas gracias por tus aportes... Me hacen ver la cantidad de opciones que tengo para poder mejorar mi base de datos y sobre todo ver que crear una base no es solo introducir datos...

Considerare todas tus propuestas y las realizaré en un modelo de prueba para ver cual acaba convenciendo

Si tuviera alguna duda me pondría en contacto contigo.

Gracias de nuevo.