El Procesamiento de Transacciones en Oracle Forms (Parte 1)

Objetivos:

• Explicar el proceso utilizado por Oracle Forms para aplicar cambios a la base de datos.

• Describir la secuencia de eventos del COMMIT.

• Complementar el procesamiento de transacciones.

• Asignar números secuenciales a los registros a medida que se aplican en las tablas.

• Implementar el arreglo DML.

______________________________________________________________________________________

Descripción General del Procesamiento de transacciones.

Al aplicar los cambios realizador por un usuario a la base de datos, Forms Builder le permite disparar Triggers para así alterar o agregar funcionalidad al procesamiento predeterminado. Esta publicación muestra cómo crear Triggers que pueden realizar tareas adicionales durante las distintas etapas de una transacción.

Cuando se solicita a Forms que guarde los cambios realizados por el usuario, se lleva a cabo un proceso que involucra eventos relacionados a la transacción de la base de datos. Este proceso incluye:
• El Procesamiento de Transacciones Predeterminado de Forms (Default Forms Transaction Processing): aplica los cambios del usuario a las tablas base.
• La Ejecución de Triggers Transaccionales (Firing Transactional Triggers): necesarios para agregar acciones adicionales o modificar las predeterminadas en el proceso de guardado.
Cuando todas estas acciones se completan con éxito, Forms confirma la transacción y hace que los cambios sean permanentes.

El proceso de transacción ocurre como resultado de cualquiera de las siguientes acciones:
• El usuario procede a Guardar los cambios ya sea presionando F10, presionando el botón Guardar de la Barra de Herramientas predeterminadas de Forms o mediante el menú: Actions->Save.
• El built-in COMMIT_FORM es llamado desde un Trigger.
En cualquier caso, el proceso implica dos fases, Aplicar (Posting) y Confirmar (Committing):
Posting: se escriben los cambios del usuario en las tablas base, utilizando sentencias implícitas INSERT, UPDATE y DELETE generadas por Forms. Los cambios se aplican en secuencia de acuerdo al orden de los bloques tal como aparecen en el navegador de objetos de Forms Builder. Para cada bloque, las eliminaciones (DELETE) se realizan primero, seguidas de inserciones (INSERT) y luego las actualizaciones (UPDATE). Si el programador lo decide así, los Triggers transaccionales se desencadenan durante este ciclo.
El built-in POST por si soló puede invocar este proceso de Posting.
Committing: Esto realiza la confirmación en la base de datos, haciendo que los cambios aplicados sean permanentes y liberando cualquier bloqueo.

Otros eventos relacionados con las transacciones incluyen rollbacks, savepoints y locking.
• Rollbacks: Forms descartará los cambios aplicados hasta un puntos de rescate (Savepoint) si se produce un error en su procesamiento predeterminado o cuando falla un Trigger Transaccional.
De forma predeterminada, se informa al usuario del error a través de un mensaje, y una inserción o actualización fallida da como resultado que el registro se vuelva a mostrar. El usuario puede intentar corregir el error antes de intentar guardar de nuevo.
• Savepoints: Forms automáticamente emite puntos de rescate (Savepoints) en una transacción, y se retrotraerá al último punto de rescate si ocurren ciertos eventos. En general, estos Savepoints son para uso interno de Forms, pero ciertos built-in, como EXIT_FORM, pueden solicitar una reversión al último Savepoint utilizando la opción TO_SAVEPOINT.
• Locking: Cuando actualiza o elimina los registros de la tabla base en una aplicación Forms, automáticamente se aplican los bloqueos de la base de datos. Los bloqueos también se aplican durante la fase de aplicación (Posting) de una transacción y para las sentencias DML que utiliza explícitamente en su código.
Nota: Las sentencias SQL COMMIT, ROLLBACK y SAVEPOINT no pueden invocarse directamente desde un Trigger. Si se incluyen an algún trigger o program unit, Forms tratará el COMMIT como COMMIT_FORM, y el ROLLBACK como el CLEAR_FORM.

______________________________________________________________________________________

La Secuencia de Eventos del COMMIT.
La secuencia de eventos de confirmación (cuando el tamaño del Array DML es 1) es la siguiente:
1. Validar el Form.
2. Procesa los Savepoints.
3. Se dispara el Trigger Pre-Commit.
4. Valida el bloque (todos los bloques en orden secuencial).
5. Realiza el DML:

Para todos los registros eliminados del bloque (en orden inverso al borrado):

--Dispara el Trigger Pre-Delete.
--Elimina la fila de la tabla base o dispara el Trigger On-Delete.
--Dispara el Trigger Post-Delete.
Para todos los registros insertados o actualizados del bloque en orden secuencial:

• Si es un registro insertado:
--Se copia el valor del Item.
--Dispara el Trigger Pre-Insert.
--Verifica la singularidad del registro.
--Inserta la fila en la tabla base o dispara el Trigger On-Insert.
--Dispara el Trigger Post-Insert.
• Si es un registro actualizado:
--Dispara el Trigger Pre-Update.
--Verifica la singularidad del registro.
--Actualiza la fila en la tabla base o se dispara el Trigger On-Update.
--Dispara el Trigger Post-Update.
6. Dispara el Trigger Post-Forms-Commit.
Si la operación actual es COMMIT, entonces:
7. Se Emite una sentencia SQL-COMMIT.
8. Se Dispara el Trigger Post-Database-Commit.

______________________________________________________________________________________

Características de los Triggers COMMIT.
Ya hemos visto cuando son disparados los trigger tipo commit durante el flujo normal de procesamiento del COMMIT. La siguiente tabla brinda información detallada acerca de las condiciones bajo las cuales estos trigger son disparados.

Por lo general, no es necesario codificar Triggers COMMIT, y la posibilidad de errores en la codificación es alta. Debido a esto, use dichos triggers solo si su aplicación requiere un procesamiento especial en el momento de la confirmación (COMMIT).

Un uso válido de los Triggers COMMIT es distribuir las sentencias DML a las tablas subyacentes cuando está realizando DML en un bloque en función de una vista que contiene JOINs. Sin embargo, el uso de bloques basados en tablas de base de datos en lugar de Triggers COMMIT puede eliminar la necesidad de definir dichos triggers.

Nota: Si falla un Trigger COMMIT, excepto el Trigger Post-Database-Commit, la transacción se retrotrae al punto de rescate (savepoint) que se estableció al comienzo del procesamiento del commit actual. Esto también significa que las aplicaciones (posting) no confirmadas emitidas antes del punto de rescate no se revierten ni se guardan.

Trigger	Característica
Pre-Commit	Dispara una vez durante el proceso COMMIT, antes de que se procesen los bloques de tabla base; dispara si hay cambios en los Items de la tabla base en el Form o si los cambios se han publicado pero aún no se han confirmado (siempre se activa en caso de aplicaciones (posting) no confirmadas, incluso si no hay cambios que aplicar).
Pre- y Post-DML	Dispara para cada registro marcado para insertar, actualizar o eliminar, justo antes (Pre-) o después (Post-) de insertar, actualizar o eliminar la fila en la base de datos.
On-DML	Dispara para cada registro marcado para insertar, actualizar o eliminar reemplazando así el funcionamiento habitual o predeterminado de Forms al momento de ejecutar una sentencia DML: INSERT, UPDATE o DELETE (Esto incluye llamadas a built-ins como INSERT_RECORD, UPDATE_RECORD o DELETE_RECORD).
Post-Forms-Commit	Dispara una vez durante el procesamiento del COMMIT, justo después de procesar los bloques de la tabla base pero antes de que se emita la sentencia SQL-COMMIT; se dispara incluso si no hay cambios para postear o confirmar (COMMIT).
Post-Database-Commit	Dispara una vez durante el procesamiento del COMMIT, justo después de emitir la sentencia SQL-COMMIT; se dispara incluso si no hay cambios para postear o confirmar (también aplica para la sentencia SQL-COMMIT en si misma).

______________________________________________________________________________________

Usos comunes de los Triggers COMMIT.
Para poder eligir el Trigger COMMIT con la funcionalidad ideal para su requerimiento, debe conocer exactamente cuando estos Triggers son disparados. Para ayudarlo con esto, la siguiente tabla muestra los usos más comunes de dichos Triggers.

Siempre que sea posible, implemente funcionalidades tales como escribir en una tabla de diario, suministrar automáticamente valores de columna y verificar restricciones en el servidor.

Nota: El bloqueo también es necesario para el procesamiento de transacciones. Puede usar el Trigger On-Lock si desea modificar o personalizar el bloqueo predeterminado de Forms.

Use sentencias DML solo en Triggers Commit; de lo contrario, éstas no serán incluidas en la administración realizada por Forms relativa al procesamiento de los COMMITs. Esto puede conducir a resultados inesperados y no deseados.

Trigger	Uso Común
Pre-Commit	Checks user authorization; sets up special locking requirements Verifica la autorización (Privilegios) del usuario; establece requisitos especiales de bloqueo.
Pre-Delete	Escribe en tablas de diario; implementa la eliminación restringida o en cascada.
Pre-Insert	Escribe en tablas de diario; llena columnas generadas automáticamente (Valores Calculados); genera números de secuencia; comprueba las restricciones.
Pre-Update	Escribe en tablas de diario; llena columnas generadas automáticamente (Valores Calculados); comprueba las restricciones; implementa actualizaciones restringidas o en cascada.
Post-Delete, Post-Insert, Post-Update	Raramente usados.
On-Delete, On-Insert, On-Update	Reemplaza las sentencias DML predeterminadas del bloque; por ejemplo, con éstas es posible implementar una pseudo eliminación o actualización de una una vista con unión.
Post-Forms-Commit	Comprueba complejas restricciones de múltiples filas.
Post-Database-Commit	Determina si el Commit fue exitoso; determina si hay cambios aplicados (Posting) pero no confirmados.

______________________________________________________________________________________

La Vida de un UPDATE.

El siguiente ejemplo muestra un escenario donde es recomendable utilizar un Trigger Commit. Considera esta operación de actualización:

Ejemplo:
El precio de un producto está siendo actualizando en un Form. Después de que el usuario consulta el registro, se producen los siguientes eventos:
1. El usuario actualiza el Item Precio. Inmediatamente se realiza el cambio en el Item, el registro de la base de datos se bloqueada.
2. El usuario guarda el cambio, iniciando el proceso de transacción.
3. El trigger Pre-Update (si está presente) se dispara. En esta etapa, el valor del Item y el de la columna de base de datos siguen siendo diferentes, porque la actualización no se ha aplicado a la tabla base. El Trigger podría comparar los dos valores, por ejemplo, para asegurarse de que el nuevo precio no sea inferior al existente.
4. Forms aplica el cambio realizado por el usuario al registro de la base de datos. De ahora en adelante el Item y la columna contienen el mismo valor.
5. El Trigger Post-Update (si está presente) se dispara. A partir de ahora ya no es posible comparar el valor de Item con el de la columna, porque la actualización ya se ha aplicado. Sin embargo, la base de datos de Oracle conserva el valor de la columna anterior como dato de reversión (rollback data), por lo que una falla de este Trigger restablecería el valor original.
6. Forms emite el Commit en la base de datos, descartando así los datos de reversión, liberando bloqueos y haciendo permanentes los cambios. El usuario recibe el mensaje "Transacción completada (Transaction Completed).

______________________________________________________________________________________

Validación al Eliminar (DELETE).

Los bloques Maestro-Detalle que están vinculados por una relación con la regla de eliminación no aislada (nonisolated deletion rule) impiden que los registros maestros se eliminen si existen filas detalles que coincidan.

Sin embargo, es posible que se desee implementar una comprobación similar cuando se aplica una eliminación:
• Una comprobación para garantizar que ningún otro usuario haya insertado filas detalles de un registro maestro marcado para su eliminación en el Form (en una base de datos Oracle, esto generalmente se realiza mediante una restricción (Constraint) o un Trigger de base de datos).
• Una verificación de los datos del Form, o verificaciones que involucran acciones dentro de la aplicación.

Nota: Si al momento de crear un Bloque de Base de Datos con el Asistente (Data Block Wizard) marcas la opción Enforce data integrity, Forms Builder crea automáticamente los Triggers relacionados para implementar las restricciones de dicha tabla.

Ejemplo:
DECLARE
CURSOR cur_ordenes IS
SELECT 'Existen'
FROM ORDERS
WHERE customer_id = :CUSTOMERS.customer_id
;
v_existen VARCHAR2(7);
BEGIN
OPEN cur_ordenes;
FETCH cur_ordenes INTO v_existen;
CLOSE cur_ordenes;

IF v_existen IS NOT NULL THEN
MESSAGE('No puede eliminar este cliente, existen ordenes que pertenecen al mismo.');
RAISE form_trigger_failure;
END IF;
END;

/*Este Trigger Pre-Delete en el bloque COSTUMERS impide la eliminación de algún cliente si el mismo tiene pedidos existentes.*/

______________________________________________________________________________________

Asignando Números Secuenciales a los Registros. 

Es bueno tener presente que es posible asignar valores predeterminados de una de una secuencia de Oracle a los Items de Forms, y así proporcionar automáticamente claves únicas para los registros en su creación. Sin embargo, si el usuario no completa algún registro, el número de secuencia asignado se "desperdicia".

Un método alternativo es asignar claves únicas a los registros desde un Trigger Pre-Insert, justo antes de su inserción en la tabla base, momento en el cual el usuario haya completado el registro y emitido el Commit.

La asignación de claves únicas en la fase de posteo puede:
• Reducir los huecos en los números asignados.
• Reducir el tráfico de datos en la creación de registros, especialmente si los registros se descartan antes de guardar.

Ejemplo:
El siguiente Trigger Pre-Insert en el bloque ORDERS asigna un ID de orden de la secuencia ORDERS_SEQ, que se escribirá en la columna ORDER_ID justo despues de iniciar el proceso de inserción.
BEGIN

SELECT ORDERS_SEQ.nextval
INTO :ORDERS.order_id
FROM SYS.dual; 

END;
Nota: Las propiedades Insert Allowed y Keyboard Navigable del item ORDERS.order_id deben estar en No, para que el usuario no ingrese un ID manualmente.

También puede asignar números de secuencia de una tabla. Por lo general al usar este método, nos valemos de dos Triggers transaccionales:
• Use Pre-Insert para seleccionar el siguiente número disponible de la tabla de secuencia (bloqueando la fila para evitar que otros usuarios seleccionen el mismo valor) e incremente el valor en la cantidad requerida.
• Use Post-Insert para actualizar la tabla de secuencia, registrando el nuevo valor superior para la secuencia.

______________________________________________________________________________________

Mantener un Rastro de Auditoría

Es posible que desee utilizar los Triggers transaccionales tipo Post para registrar la información de auditoría sobre los cambios aplicados a las tablas base. En algunos casos, esto puede implicar la duplicación de inserciones o actualizaciones en tablas de bitácora (Log) que sirven como copias de seguridad o para registrar estadísticas cada vez que se produce una operación DML.

Si los cambios de la tabla base se confirman al final de la transacción, la información de auditoría también se confirmará.

Ejemplo:
Este Trigger Post-Update escribe el ID del registro actual en la tabla UPDATE_AUDIT, junto con el tiempo y el usuario que realizó la actualización.

BEGIN

INSERT INTO update_audit (id, timestamp, who_did_it)

VALUES  ( :ORDERS.order_id, SYSDATE, USER );

END;

Ejemplo:
Este Trigger Post-Insert suma al total acumulado de inserciones en la transacción, que se registra en la variable global INSERT_TOT.

BEGIN

:GLOBAL.insert_tot := TO_CHAR(TO_NUMBER(:GLOBAL.insert_tot)+1);

END;

______________________________________________________________________________________

Probando los Resultados de los Triggers DML

Cuando realiza DML en Triggers transaccionales, es posible que requiera probar los resultados.
A diferencia de las sentencias SELECT, las sentencias DML no generan excepciones cuando se procesan cero o múltiples filas. PL/SQL proporciona algunos atributos útiles para obtener resultados relacionados con el cursor implícito utilizado para procesar la última sentencia SQL (en este caso, DML).

Ejemplo:
Este Trigger When-Button-Pressed registra la fecha de posteo como la fecha de la orden actual.
BEGIN
UPDATE ORDERS
SET order_date = SYSDATE
WHERE order_id = :ORDERS.order_id;
IF SQL%NOTFOUND THEN
MESSAGE('0 ordenes fueron actualizadas.');
RAISE form_trigger_failure;
END IF;
END;
/*El anterior ejemplo muestra como desplegar un mensaje en caso de que el último intento de actualización sea fallido. Si no existe una orden con el order_id en cuestión el usuario recibiría el error: '0 ordenes fueron actualizadas.'*/

Obtención de información del cursor en PL/SQL.

PL/SQL Cursor Attribute	Values
SQL%FOUND	TRUE:  Indica > 0 rows processed FALSE: Indica 0 rows processed
SQL%NOTFOUND	TRUE:  Indica 0 rows processed FALSE: Indica > 0 rows processed
SQL%ROWCOUNT	Integer Indica el número de registros procesados.

Nota: Los Triggers que contienen DML de la tabla base pueden afectar negativamente al comportamiento habitual del Form, esto porque las sentencias DML pueden hacer que algunas de las filas de la base de datos se bloqueen. Si no altera el procesamiento predeterminado al hacer COMMIT, Forms proporcionará sentencias DML para cada registro de base de datos que se inserte, actualice o se elimine.

Reglas
• Estas sentencias DML pueden disparar Triggers de base de datos asociados con las tablas en cuestión.
• Forms utiliza el ROWID solo cuando la propiedad de bloque Key Mode está establecida en Unique (o Automatic, por defecto). De lo contrario, la clave principal (Primary Key) se usa para construir la cláusula WHERE.
• Si Forms inserta con éxito una fila en la base de datos, también recupera el ROWID para esa fila.
• Si la propiedad del bloque Update Changed Columns Only está establecida en Sí, solo las columnas base con valores modificados se incluyen en la sentencia UPDATE.
• Si la propiedad de bloque Enforce Column Security está establecida en Sí, todas las columnas base para las cuales el usuario actual no tiene privilegios de actualización se excluyen de la sentencias UPDATE.

Forms no emite sentencias de bloqueo durante el procesamiento COMMIT predeterminado; se emiten tan pronto como cuando un usuario actualiza o elimina un registro en el Form. Si configura la propiedad de bloque Locking Mode en delayed, Forms bloquea el registro correspondiente y espera hasta que se emita el COMMIT.

______________________________________________________________________________________

Continuación...

Debido a que el tema en cuestión es bastante extenso decidimos dividirlo para evitar que éste sea abrumador. Segunda parte: El Procesamiento de Transacciones en Oracle Forms (Parte 2).

______________________________________________________________________________________

Fuente: Oracle Forms Developer 10g: Build Internet Applications.