Problema al Crear un Trigger

[sharton]

Hola Buenas tardes a todos!

Quisiera ver si puedes ayudarme con lo siguiente:

Tengo mi base de datos Oracle una tabla llamada Alumnos, donde tiene 9 campos pero quisiera que solo la encargada llene 7 registros mediante un formulario(pero ese no es el problema) de las cuales esos 2 campos restantes quiero llenarlos con un trigger; les explico acá esta mi tabla:

CREATE TABLE ALUMNOS
(
ID_ALUMNO CHAR(3) PRIMARY KEY,
NOMBRE VARCHAR2(50) NOT NULL,
APELLIDO VARCHAR2(50) NOT NULL,
SEXO VARCHAR2(1) NOT NULL,
F_NAC DATE NOT NULL,
PAGO NUMBER NOT NULL,
CANT_CUR_DES NUMBER NOT NULL,
USUARIO VARCHAR2(30),
FECHA DATE
)

pues esos 2 últimos campos, que es usuario y fecha, se debiera llenar al registrar un nuevo registro mediante un trigger, la cual he intentado de varias formas y no me sale y me gustaría bastante que me ayuden por favor, ya que tengo solo hasta el domingo, para solucionarlo.

CREATE OR REPLACE TRIGGER TR_NAME
AFTER INSERT ON ALUMNOS
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
UPDATE ALUMNOS
SET ID_ALUMNO=:OLD.ID_ALUMNO,
NOMBRE=:OLD.NOMBRE,
APELLIDO=:OLD.APELLIDO,
SEXO=:OLD.SEXO,
F_NAC=:OLD.F_NAC,
PAGO=:OLD.PAGO,
CANT_CUR_DES=:OLD.CANT_CUR_DES,
:NEW.USUARIO=USER,
:NEW.FECHA=SYSDATE;
END;

la cual al insertar debiera, activarse ese trigger para aumentar esos 2 últimos datos, y así sabre, quien lo registro y la fecha y hora en que lo hizo!

INSERT INTO ALUMNOS VALUES ('A01','JUNIOR','CÉSPEDES','M','22-08-1987','180','1','','');

[gnzsoloyo]

pues esos 2 últimos campos, que es usuario y fecha, se debiera llenar al registrar un nuevo registro mediante un trigger

La verdad es que para llenar esos datos ni siquiera necesitas un TRIGGER. Normalmente se hace en el mismo INSERT, cuando se lo crea...

Hacerlo en un TRIGGER no le aporta absolutamente ninguna ventaja, y le agrega una complicación innecesaria al sistema.
Los trigger se deben usar únicamente cuando es estrictamente necesario por necesidades del sistema, y cuando el procesos a realizar no se puede solventar de ninguna otra forma.
Ten en cuenta que es algo que se ejecutará siempre.

[jc3000]

No debes complicarte la vida con un update innecesario.

Esto te lo soluciona :

CREATE OR REPLACE TRIGGER TR_NAME
AFTER INSERT ON ALUMNOS
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
:NEW.USUARIO=USER,
:NEW.FECHA=SYSDATE;
END;

Por otra parte, te recomendaría que en usuario no metas el de BBDD, sino el de red. A no ser que useis como usuarios de aplicacion uno de BBDD por cada usuario que maneja la aplicación.

gnzsoloyo : Los triggers de auditoria en los que se informa quien ha insertado , actualizado o borrado un registro son muy importantes y esos datos ( USUARIO y FECHA ) deben de rellenarse automaticamente, no mediante el insert-update y "delete" correspondiente.

Una buena operativa es que cada vez que se crea una tabla, se cree el correspondiente trigger de auditoria.

[gnzsoloyo]

gnzsoloyo : Los triggers de auditoria en los que se informa quien ha insertado , actualizado o borrado un registro son muy importantes y esos datos ( USUARIO y FECHA ) deben de rellenarse automaticamente, no mediante el insert-update y "delete" correspondiente.

Mi estimado: Eso lo se de sobra, pero no era a donde apuntaba la pregunta de sharton...

Por otro lado, insisto que crear un trigger para algo que puede hacer en el mismo insert es completamente innecesario.

Respecto a las auditoirías, lo que propones de usar el usuario de servidor y no el de base puede no resultar una buena práctica porque eso te dice quién es el responsable último, pero no quien hace la operación, si en el sistema un usuario puede trabajar "a nombre de otro", como por ejemplo en el caso de usuario de ventas que posee vendedores subalternos, ninguno de los cuales se registra separadamente. En ese caso, tomar el usuario del servidor, no es una buena idea
No es un caso "excepcional", sino una práctica habitual en ciertos sistemas complejos con muchas restricciones para crear usuarios.
Precisamente yo trabajo en un sistema de esas características, que tiene alcance nacional. En el caso de la empresa para la que trabajo, una de las directivas del manual de buenas prácticas que posee el área de desarrollo de BBDD dice expresamente que no se deben crear triggers para tareas de auditoría, porque exigen demasiados accesos a disco, quitando performance. Toda la auditoría se realiza por operaciones asincrónicas, y los asientos de las tablas tienen que ir con el user del sistema (no el del servidor) y fecha de la modificación, que es lo que yo planteaba.

Como ves, la auditoría por triggers no es una regla absoluta.

[jc3000]

No compañero, como bien dices reglas absolutas no hay, y menos en este mundillo.

Vosotros trabajais de una manera y nosotros de otra, ambas dos igual de buenas puesto que responden a nuestras necesidades. Vuestro manual de buenas prácticas dice no a los triggers de auditoría, en cambio el nuestro dice todo lo contrario.