El Procesamiento de Transacciones en Oracle Forms (Parte 2)

Objetivos:

• Complementar el procesamiento de transacciones.

• El uso de Variables de Sistema en conjunto con los Triggers Transaccionales.
• Implementar la Matriz DML.

Nota: esta publicación es la continuación de El Procesamiento de Transacciones en Oracle Forms (Parte 1), de modo que es recomendable tener los conocimientos expuestos ahí para una mejor comprensión de lo aquí expuesto.

______________________________________________________________________________________

Anulando el Procesamiento Transaccional Predeterminado.

En publicaciones anteriores hemos visto que algunos Triggers Commit se pueden usar para reemplazar las sentencias DML predeterminadas que Forms emite durante el procesamiento Commit. Puede utilizar varios otros Triggers para anular el procesamiento predeterminado de transacciones en Forms.

Triggers Transaccionales.

Todos los Triggers  que están relacionados con el acceso a una fuente de datos se denominan Triggers Transaccionales. Los Triggers Commit forman un subconjunto de ellos. Otros ejemplos incluyen Triggers  que se activan durante el inicio de sesión y cierre de sesión o durante consultas realizadas en el origen de datos.

Trigger	Do-the-Right-Thing Built-In
On-Check-Unique	CHECK_RECORD_UNIQUENESS
On-Column-Security	ENFORCE_COLUMN_SECURITY
On-Commit	COMMIT_FORM
On-Rollback	ISSUE_ROLLBACK
On-Savepoint	ISSUE_SAVEPOINT
On-Sequence-Number	GENERATE_SEQUENCE_NUMBER

Nota: Estos Triggers están destinados a ser utilizados cuando se conecta a fuentes de datos que no sean Oracle.

Triggers Transaccionales para iniciar y cerrar sesión.

Trigger	Do-the-Right-Thing Built-In
Pre-Logon	-
Pre-Logout	-
On-Logon	LOGON
On-Logout	LOGOUT
Post-Logon	-
Post-Logout	-

Usos de Triggers Transaccionales.

• Los Triggers transaccionales, excepto los Triggers Commit, están destinados principalmente a acceder a determinadas fuentes de datos distintas de Oracle.

• Los Triggers transaccionales de inicio de sesión y cierre de sesión también se pueden usar con las bases de datos de Oracle para cambiar las conexiones en tiempo de ejecución.

______________________________________________________________________________________
Forms con fuentes de datos distintas a Oracle.
Existen dos formas de ejecutar Forms con fuentes de datos distintas de Oracle:
• Use los productos Oracle Transparent Gateway.
• Escriba un conjunto apropiado de Triggers Transaccionales.

Conectando con Open Gateway:

Cuando se conecta a una fuente de datos que no sea Oracle con un producto Open Gateway, debe tener en cuenta estas propiedades transaccionales:

• La propiedad del Módulo Forms Cursor Mode.
• La propiedad del Módulo Forms Savepoint Mode.
• La propiedad de Bloque Key Mode.
• La propiedad de Bloque Locking Mode.

Puede configurar estas propiedades para especificar cómo Forms debe interactuar con el origen de datos. La configuración específica depende de las capacidades de la fuente de datos.

Usando Triggers Transaccionales.

Si no existen controladores Open Gateway para su origen de datos, debe definir Triggers Transaccionales. A partir de estos Triggers, debe llamar programas 3GL que implementan el acceso a la fuente de datos.

Propiedad Bloque de Base de Datos (Database Data Block).

Esta propiedad (de bloque) identifica un bloque como un bloque de control transaccional; es decir, un bloque de control que debe tratarse como un bloque de tabla base. Al establecer esta propiedad en Sí, se asegura que los Triggers Transaccionales dispararán para el bloque, aunque no sea un bloque de tabla base. Si establece esta propiedad en Sí, debe definir todos los Trigger transaccionales On-Event, de lo contrario recibirá un error durante la generación del Form.

______________________________________________________________________________________
Obteniendo y configurando el Estado del Commit (Commit Status).

Si desea procesar un registro en su Form, resulta útil saber si el mismo fue cambiado o está tal cual en la base de datos. Puede usar built-ins y variables de sistema para obtener esta información.

¿Cuál es el estado (Commit Status) de un registro?

El estado de un registro de un bloque de base de datos determina cómo se procesará durante el siguiente proceso de Commit. Por ejemplo, el registro se puede insertar, actualizar o no procesar en absoluto.

Los Valores de SYSTEM.RECORD_STATUS:

Valor	Descripción
NEW	Indica que el registro se ha creado, pero que ninguno de sus Items se ha cambiado aún (es posible que el registro se haya llenado con los valores predeterminados).
INSERT	Indica que uno o más items en un registro recién creado han sido cambiados (El registro se procesará como una inserción durante el próximo proceso de confirmación (Commit) si su bloque tiene el estado CHANGED; ver más adelante. Tenga en cuenta que cuando cambia un item de control de un registro con estado en NEW , el estado del registro también se convierte en INSERT).
QUERY	Indica que el registro corresponde a una fila de la base de datos, pero que ninguno de sus items han sido cambiados.
CHANGED	Indica que se han cambiado uno o más item de un registro extraído de la base de datos (el registro se procesará como una actualización (o eliminación) durante el siguiente proceso de confirmación).

Los Valores de SYSTEM.BLOCK_STATUS:

Valor	Descripción
NEW	Indica que todos los registros del bloque tienen el estado NEW (Tenga en cuenta que un bloque de tabla base con el estado NEW también puede contener registros con el estado INSERT causado por el cambio de items de control).
QUERY	Indica que todos los registros del bloque tienen el estado QUERY si el bloque es de base de datos (un bloque de control tiene el estado QUERY si contiene al menos un registro con el estado INSERT).
CHANGED	Indica que el bloque contiene al menos un registro con el estado INSERT o CHANGED si el bloque es un bloque de tabla base (El bloque se procesará durante el próximo proceso de confirmación. Tenga en cuenta que un bloque de control no puede tener el estado CHANGED).

Los Valores de SYSTEM.FORM_STATUS:

Valor	Descripción
NEW	Indica que todos los bloques del Form  tienen el estado NEW.
QUERY	Indica que al menos un bloque del Form tiene el estado QUERY y todos los otros bloques tienen el estado NEW.
CHANGED	Indica que al menos un bloque del Form tiene el estado CHANGED.

El uso de built-ins para obtener el Estado del Commit.

Las variables de sistema SYSTEM.RECORD_STATUS y SYSTEM.BLOCK_STATUS se aplican al registro y al bloque donde está ubicado el cursor. Puede usar built-ins para obtener el estado de otros bloques y registros.

Built-ins	Descripción
GET_BLOCK_PROPERTY	Use la propiedad STATUS para obtener el estado del bloque especificado.
GET_RECORD_PROPERTY	Use la propiedad STATUS para obtener el estado del registro especificado de algún bloque.
SET_RECORD_PROPERTY	Establezca la propiedad STATUS del registro especificado en el bloque especificado con una de las siguientes constantes: ·         NEW_STATUS ·         INSERT_STATUS ·         QUERY_STATUS ·         CHANGED_STATUS

Sintaxis

• GET_BLOCK_PROPERTY  ('BLOCK',   PROPERTY);
• GET_RECORD_PROPERTY  ( RECORD_NUMBER,   'BLOCK',   PROPERTY);
• SET_RECORD_PROPERTY  ( RECORD_NUMBER,   'BLOCK',   PROPERTY,   'VALUE');

Ejemplo:

Si el tercer registro del bloque ORDERS es un registro de base de datos modificado, establezca el estado nuevamente en QUERY.

BEGIN
  IF GET_RECORD_PROPERTY(3, 'ORDERS',status)= 'CHANGED' 
  THEN
  SET_RECORD_PROPERTY(3, 'ORDERS', status,  
                         query_status);
  END IF;
END;

Advertencias:

• No confunda el estado de confirmación (COMMIT STATUS) con el estado de validación.

• El estado de confirmación se actualiza durante la validación.

______________________________________________________________________________________
Matriz DML (Array DML).

Procesamiento Matriz

El procesamiento  matriz es una opción en Forms Builder que altera la forma en que se procesan los registros. El comportamiento predeterminado de Forms es procesar los registros de uno en uno. Al habilitar el procesamiento matriz, puede procesar grupos de registros a la vez, reduciendo el tráfico en la red y, por lo tanto, aumentando el rendimiento. Esto es especialmente importante en las aplicaciones web. Con el procesamiento matriz, una estructura (una matriz) que contiene múltiples registros se envía o se devuelve desde el servidor para su procesamiento.

Forms Builder permite extraer un conjunto de registros en forma de matriz y a su vez permite procesarlos en forna de DML matriz. Tanto para consultas como para operaciones DML, puede determinar el tamaño de la matriz para así optimizar el rendimiento según sus necesidades.

El procesamiento de matriz está disponible para consultas y operaciones DML en bloques basados en tablas de base de datos, vistas, procedimientos y subconsultas; no es compatible con bloques basados en Triggers Transaccionales.

Efecto de la Matriz DML en Triggers Transaccionales.

Con DML Array Size establecido en 1, los Triggers Pre-Insert, Pre-Update y Pre-Delete disparan por cada registro nuevo, modificado y eliminado; se emite el DML y se dispara el Post-trigger para ese registro.

Con DML Array Size configurado en un número mayor a 1, son disparados los triggers Pre- para todas las filas nuevas, modificadas y eliminadas; todas las sentencias DML se emiten y todos los triggers Post- se activan.

Si cambia 100 filas y DML Array Size es 20, obtendrá 100 Pre-triggers, 5 matrices de 20 sentencias DML y 100 Post-triggers.

______________________________________________________________________________________

Cómo Implementar la Matriz DML.

1. Para establecer preferencias:

--Seleccione Editar> Preferencias.

--Haga clic en la pestaña Runtime.

--Seleccione la casilla Procesamiento de Matrices.

2. Para establecer propiedades:

--En el Navegador de objetos, seleccione el nodo Bloques de datos.

--Seleccione el Bloques de datos en question y despliegue sus propiedades (F4).

--En la categoría de Advanced Database, establezca la propiedad DML Array Size en un número que represente la cantidad de registros a ser procesados en forma de matriz. También puede configurar esta propiedad mediante programación.

Nota: Cuando la propiedad DML Array Size es mayor que 1, debe especificar la clave principal. El KEY MODE aún puede ser UNIQUE.

El servidor de Oracle usa ROWID para identificar la fila, excepto después de una inserción matriz. Si actualiza un registro en la misma sesión que lo insertó, el servidor bloquea el registro utilizando la clave principal.

______________________________________________________________________________________

Resumen.

En esta publicación en conjunto con El Procesamiento de Transacciones en Oracle Forms (Parte 1), debes haber aprendido a:

• Aplicar cambios a la base de datos, Forms emite los posting y los commits.
• La secuencia de eventos del Commit:
1. Se Valida el Form.
2. Se Procesan los puntos de rescate.
3. Se disparan los Triggers Pre-.
4. Se Validan los bloques en orden secuencial.
5. Se ejecutan los DML:
--Secuencia al eliminar registros: Se dispara el Pre-Delete; Se elimina el registro o se dispara el On-Delete; Se dispara el Post-Delete.
--Secuencia al insertar registros: Se copia el valor del Item; Se dispara el Pre-Insert; Se verifica la singularidad del registro; Se inserta el registro o se dispara el On-Insert; Se dispara el Post-Insert.
--Secuencia al  actualizar registros: Se dispara el Pre-Update; Se verifica la singularidad del registro; Se actualiza el registro o se activa el On-Update; Se dispara el Post-Update.
6. Se dispara el Trigger Post-Forms-Commit.
Si la operación actual es COMMIT, entonces:
7. Emite la sentencia SQL-COMMIT.
8. Se Dispara el Trigger Post-Database-Commit.
• Puede complementar el procesamiento de transacciones con Triggers:
--Pre-Commit: se dispara una vez si se realizan cambios en el Form.
--[Pre | Post] - [Update| Insert | Delete].
--On - [Update| Insert | Delete]: Se dispara por cada registro, reemplazando el DML predeterminado. Realiza las funciones predeterminadas con Built-ins: [UPDATE|INSERT|DELETE]_RECORD.
• Utilizar el Trigger Pre-Insert para asignar números de secuencia a los registros a medida que se aplican a las tablas.
• Verificar o cambiar el estado de confirmación (Commit):
–GET_BLOCK_PROPERTY, [GET | SET]_RECORD_STATUS
–:SYSTEM.[FORM | BLOCK | RECORD]_STATUS• Usar Triggers Transaccionales para anular o añadir funcionalidad al procesamiento predeterminado del Commit.
• El uso de la Matriz DML para reducir los viajes de ida y vuelta en la red con la propiedad de bloque DML Array Size.

______________________________________________________________________________________

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

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.