Respaldar registro en otra tabla antes de borrarlo en Access

Necesito guardar un registro que sirva de respaldo de cada registro que sea eliminado en una tabla Access, para poder revisar las eliminaciones de registros y aplicar control posterior. Si saben como hacerlo con Macros de Datos seria ideal porque según entiendo Microsoft Access no soporta Triggers. En caso que no se pueda hacer con Macro de datos, les ruego apoyarme con algunas opciones de código vba asociado a un botón de formulario "borrar".

2 respuestas

Respuesta
2

La solución "equivalente" a los triggers en Access son las macros de datos. En tu caso has de usar la macro "después de eliminar", y será una cosa así:

Es decir, primero pones la acción CrearRegistro y le indicas tu tabla de respaldo, y dentro de esa acción, por cada campo que quieras respaldar, la acción EstablecerCampo, con el nombre del campo de destino en Nombre y en Valor usas la expresión [Antiguo].[NombreCampo]

Un saludo.


Me olvidaba comentarte, si no te reconoce Antiguo, usa Old

Gracias por tu apoyo Sveinbjorn El Rojo. Superagradecido por tu respuesta porque hay muy poco sobre Macro de Datos publicado o por lo menos yo no lo había conseguido, y me das muchísimas ideas para hacer otras cosas. Pero me queda una duda en este caso. Pareciera que las Macros de Datos crean conflictos cuando tienes un campo denominado [Nombre] que lo tengo en muchísimas tablas en mis aplicaciones. Te explico lo que hice a ver si hice algo mal. Inicialmente lo probé con mis datos reales y me generaba errores. Entonces cree dos tablas con los mismos nombres que tu utilizaste para asegurarme que estaba entendiendo correctamente tu planteamiento pero tuve que modificar el campo [Nombre] porque no hacia el respaldo. Te explico el paso a paso a ver si se identifica el error y no volver a cometerlo:

1. La tabla TTrabajadores que creé contenía dos campos:

2. Y a esa tabla le añadi 3 registros:

3. Luego cree una nueva tabla donde se guardarían los registros eliminados y la llame igual que lo hiciste tu TBackupTrab con los mismos campos de la tabla TTrabajadores pero agregándole el sufijo Backup para poder diferenciar los nombres de campos en la elaboración de la Macro de datos y para ver si el problema con el nombre de campo [Nombre] en las dos tablas era la causa del error.

4. Luego hice la Macro Después de Eliminar en la tabla TTrabajadores. La macro debe crear un registro en la TBackup cada vez que se borre un registro en la TTrabajadores. En EstablecerCampo en el argumento "Nombre" puse el nombre del campo [NombreBackup] de la TBackupTrab porque allí es donde se debe guardar y en el argumento "Valor" puse el nombre del campo de la TTrabajadores con el prefijo Antiguo. Igual hice con el campo Sueldo

5. Para probar si funcionaba borré el primer registro que correspondía a Pedro de la TTrabajadores

6. Y abrí la TBackupTrab para verificar si hizo el respaldo pero no apareció nada.

7. Verifico el error que señala Access en la tabla USysApplicationLog en donde dice que no encontró el identificador [Old].[Name], que por cierto yo solicite [Old].[Nombre]: ID SourceObject Data Macro Instance ID Error Number Category Object Type Description Context Created 8 TTrabajadores.AfterDelete {625E2366-3E2E-4E72-8B51-494A0A36705F} -8987 Execution Macro No se encontró el identificador '[Old].[Name]'. EstablecerCampo NombreBackup, [Old].[Name] 07/12/2017 08:15:51

8. Pareciera que el nombre del campo [Nombre] entra en conflicto con alguna palabra reservada Name. Entonces lo cambié en la tabla TTrabajadores por [NombreT] tal como sigue:

9. Actualizo en la Macro el nuevo nombre del campo [NombreT]

10. Borro el primer registro Pablo de la TTrabajadores para volver a probar

11. Abro la tabla TBackup para verificar y efectivamente se respaldó.

12. ¿Hay realmente un conflicto entre la palabra Name y el nombre del campo Nombre?

13. La otra consulta es ¿hay alguna forma de no tener que cambiar en todas mis aplicaciones la denominación del campo [Nombre] para que no genere este error?

Yo la macro de ejemplo la creé a las bravas, en una tabla que ni siquiera tenía tantos campos, por lo que inicialmente no la probé, porque así es como la tengo hecho en otras ocasiones y sin problema (claro que sin un campo Nombre)

Acabo de probarlo y me da el mismo problema que mencionas, por lo que sí, una campo llamado Nombre entra en conflicto con el funcionamiento de Access. A mi me tiene pasado en formularios o informes, que en vez de devolverme el valor del campo Nombre, me devolvía el nombre del formulario/informe, y desde entonces uso otras expresiones como nombre del campo para evitarme esos problemas...

Y en cuanto a tu última consulta, mucho me temo que no hay nada que puedas hacer para evitar ese conflicto. Te tocará ir modificando tus aplicaciones en la medida en que te vayas encontrando con ese conflicto. Siento no poderte decir nada mejor.

Un saludo.


Respuesta
1

Supongamos que estás en un formulario con los cuadros de texto Cliente, direccion, telefono y tienes un botón para eliminar ese registro(no sé como lo haces) y supongamos que tienes una tabla Historico donde vas a "guardar" los registros eliminados.

Puedes poner

docmd.setwarnings false

Docmd. Runsql"insert into Historico(cliente, direccion, telefono)values(cliente, direccion, telefono)"

Lo de setwarnings es para que no aparezca la ventana de "Va a agregar...

Los campos origen y destino no tienen porque llamarse igual, sólo deben ser de valores coherentes.

En caso de que quisieras eliminar un registro cualquiera podrías usar

docmd.runsql"insert into historico(cliente, direccion, telefono) select cliente, direccion, telefono from clientes where.... y aquí el criterio que identifique un registro en particular.

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas