Trigger auditoria

[[fjcg02]]

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

Código SQL [-]
AS
declare variable WCAMPO varchar(50);
declare variable sentencia varchar(100);
begin
  /* Trigger text */

  FOR SELECT RF.RDB$Field_Name CAMPO  /* Nombre del campo */
      FROM RDB$Relation_Fields RF
      WHERE RF.RDB$Relation_Name = 'TABLA' /* Aqui la tabla del trigger */
      INTO :WCAMPO
  DO
    BEGIN
      sentencia =  'IF (new.'||:WCAMPO ||'IS NOT NULL) THEN '||
       'BEGIN '||
         'IF (OLD.'||:WCAMPO||' <> NEW.'||:WCAMPO||' ) THEN ' ||
           'INSERT INTO AUDITORIA (IDAUDITORIA, FECHA, USUARIO, IDREGISTRO,'||
                                   'TABLA, CAMPO, VALORVIEJO,VALORNUEVO) '||
            'VALUES (GEN_ID(AUDITORIA,1), '||'''NOW'''||', NEW.USUARIOMODIF, NEW.IDPOLIZA,'||
                                 '''POLIZA'','||:WCAMPO||', CAST(OLD.'||:WCAMPO||' AS VARCHAR(50)),CAST( NEW.'||:WCAMPO||' AS VARCHAR(50)) )'';'||
       'END' ;
    END
    execute statement sentencia;

end

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

[[fjcg02]]

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.

Código SQL [-]
AS
declare variable WCAMPO varchar(50);
declare variable sentencia varchar(500);
begin
  /* Trigger text */

  FOR SELECT RF.RDB$Field_Name CAMPO  /* Nombre del campo */
      FROM RDB$Relation_Fields RF
      WHERE RF.RDB$Relation_Name = 'TABLA' /* Aqui la tabla del trigger */
      INTO :WCAMPO
  DO
    BEGIN
      WCAMPO= TRIM(WCAMPO);
      sentencia =  'IF (new.'||:WCAMPO ||'IS NOT NULL) THEN '||
       'BEGIN '||
         'IF (OLD.'||:WCAMPO||' <> NEW.'||:WCAMPO||' ) THEN ' ||
           'INSERT INTO AUDITORIA (IDAUDITORIA, FECHA, USUARIO, IDREGISTRO,'||
                                   'TABLA, CAMPO, VALORVIEJO,VALORNUEVO) '||
            'VALUES (GEN_ID(AUDITORIA,1), '||'''NOW'''||', NEW.USUARIOMODIF, NEW.IDPOLIZA,'||
                                 '''POLIZA'','''||:WCAMPO||''', CAST(OLD.'||:WCAMPO||' AS VARCHAR(50)),CAST( NEW.'||:WCAMPO||' AS VARCHAR(50)) ); '||
       'END' ;
    END
    execute statement sentencia;

end

[[fjcg02]]

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

[Casimiro Notevi]

¿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

[[fjcg02]]

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

[erickperez6]

* 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

Saludos casimiro, de verdad esta muy interesante los nuevos features de firebire 3, me gustaria leer mas detalladamente algunos de los puntos listados mas arriba, pero he dado muchas vueltas en la pagina de firebiresql.org y aparte del track detail no encuentro nada detallado de las nuevas funcionabilidades

[Cañones]

Empezado por fjcg02

Gracias por tu opinión Casimiro, pero he descartado esa idea ( la de tablas 'clon' ) ya que son tropecientas tablas.

En mi oponión, uso tablas clon como las llamas, hechas a mano. Pero le agrego cuatro campos extras, timestamp de la modificación, acción realizada(Insert, Update, Delete), usuario (de la DB) y direccion ip.

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.