FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Trigger auditoria
Hola a todos,
estoy intentando hacer un trigger que audite una serie de campos de varias tablas. Como no quiero estar poniendo el churro de campos de cada tabla, estoy intentando hacer un trigger genérico que me ayude al menos a reutilizar el código. El problema es que no consigo dar con el problema. He aquí el código maldito Pues eso, que me estoy haciendo la picha un lio. Debo decir que si hago un store proc. que me devuelva la variable SENTENCIA - que es la que se ejecuta después con el execute statement - y la copio en el ibexpert, me la ejecuta bien O sea, que estoy enrocado. Agradecería cualquier ayuda de los maestros. Gracias y un saludo
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#2
|
||||
|
||||
VAmos avanzando, ahora se compila bien. Observese que he aumentado el tamaño de la variable sentencia.
Pero a la hora de hacer un cambio en la tabla, me dice que no puede convertir a string un valor - no especifica cual - , pero que tiene que ser el propio valor del campo. Seguimos a la espera.
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#3
|
||||
|
||||
Bueno,
parece que lo que quiero hacer es imposible. El ámbito de las variables old y new no sobrepasa más allá del propio trigger, por lo que es imposible que sean accedidas desde la sentencia 'execute statement'. Por lo tanto tendré que orientar la solución hacia otro lado Un new.saludo
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#4
|
||||
|
||||
¿No sería más simple mantener una tabla donde se copiaran tal cual cada registro completo de las tablas que quieres auditar?
Por ejemplo, para la tabla "tbClientes" tendríamos "tbClientesAud", que sería igual que "tbClientes" pero sin restricción de campos nulos, valores por defecto, claves foráneas, etc. Y en los trigger después de grabar, actualizar y borrar de tbClientes se graban los datos en tbClientesAud, puedes añadir algún campo como el de fechahora de la grabación y otro para guardar si fue un borrado, update o insert. El Problema es que si son muchas tablas es un poco engorroso, no se parece en nada al "automatismo" que quieres hacer. Aquí hay algo que puede interesarte, échale un vistazo. A la espera de lo que nos traiga la versión 3 de Firebird, que promete bastante: * Monitoring * Asynchronous statement cancellation * Embedded users / SQL users management * More built-in functions * Temporary tables * SQL functions * Recursive queries * Faster outer joins * SMP support in SS * Compiled statements cache * External functions/procedures * Detailed logging/audit * SQL tracing/profilingUser permissions for metadata * Pluggable authentication modules * Security groups * Long exact numeric implementation * Domains everywhere * Regular expressions * TEXT BLOB compatible with [VAR]CHAR * Reliable logical backup * Optimizer improvements * Statement consistency/atomicy, read committed compliance * Optimized network protocol * Bi-directional indices * Referential integrity without indices * Bulk load/import * PSQL debugging extensions/hooks * Database encryption * More access paths * Full-text search * Clustering * Bi-directional cursors * XML integration
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#5
|
||||
|
||||
Gracias por tu opinión Casimiro, pero he descartado esa idea ( la de tablas 'clon' ) ya que son tropecientas tablas. Respecto a esperar nuevas funcionalidades de firebird, pues no creo que pueda esperar, es decir, seguiré para adelante.
Sí he visto un código ( que por cierto estoy buscando en la red ) que a lo más que llega es a generarte el trigger de manera automática en base a información que el usuario introduzca. Será ésta la solución que adopte, ya que me parece la más sencilla. Además, espero que los usuarios no cambien demasiado los campos que quieran auditar, dándoles ya unos triggers por defecto. Un old.saludo
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#6
|
|||
|
|||
Cita:
|
#7
|
||||
|
||||
Cita:
Por otro lado, la variable para el nombre del campo tendría que ser Varchar(255) que creo que es el máximo de caracteres posible para nombres de tablas. Espero te sirva de algo. Saludos. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Sistema de Huellas (Pistas de auditoria) | Hagen | Firebird e Interbase | 3 | 29-03-2011 14:47:12 |
Trigger dinámico para Auditoría de Tablas | jwmoreira | Firebird e Interbase | 6 | 11-03-2010 23:53:07 |
Realizar auditoria de acciones de usuarios | mantrax | Seguridad | 3 | 19-10-2007 06:42:33 |
Un trigger que dispara un procedimiento que dispara un trigger... | sitrico | Firebird e Interbase | 5 | 04-06-2007 23:05:13 |
Triggers de auditoria en firebird 1.5 | robertoe | Firebird e Interbase | 1 | 04-01-2007 05:18:11 |
|