Por Alfonso Ricaño Bringas
Cualquier instrucción SQL de definición de estructuras de datos (crear tablas, triggers, etc.) o manipulación de datos (insertar/modificar/eliminar/consultar datos) debe de darse dentro del contexto de una transacción, la cual podemos definir como un conjunto de instrucciones SQL que se aplican de manera conjunta para realizar una tarea. En otras palabras, cuando le damos una instrucción SQL a InterBase, tenemos que ejecutar esa instrucción dentro de una transacción, y podemos ejecutar más instrucciones dentro de esa misma transacción. Pero para que todas las instrucciones SQL que le dimos a InterBase tengan efecto sobre la base de datos, tenemos que confirmar (commit) la transacción, lo cual aplicará definitivamente todos los cambios inducidos por las instrucciones SQL. Si queremos cancelar todas las instrucciones de la transacción, entonces tendremos que cancelarla (rollback). Tal vez esto parezca muy complicado para algunos programadores, pero voy a poner un ejemplo concreto que hace ver la ventaja de trabajar con transacciones. Supongamos que tenemos un sistema de venta, donde vamos registrando los nombres de nuestros clientes, así como los artículos que compran. Cada vez que un nuevo cliente llega, en un formulario registramos su nombre y la lista de artículos que compró. Si trasladamos esto a un esquema relacional, tendremos que utilizar dos tablas: CLIENTES y ARTICULOS_VENDIDOS, las cuales para asegurar su integridad de datos deberán tener una llave foránea que no asegure que cada artículo vendido esté asignado a un cliente. Entonces cuando hacemos una venta, tenemos que: 1.- Agregar los datos del cliente a la tabla de de clientes. 2.- Dar de alta cada uno de los artículos en la tabla de artículos vendidos. Hay que aclarar que para poder dar de alta un artículo, debe existir por fuerza el cliente, ya que hay una llave foránea de por medio. Si todas las ventas salen como esperamos, no debe haber problema, ya que damos de alta al cliente y registramos sus artículos. Ahora, como todos los desarrolladores sabemos, hay que tener en cuenta las situaciones excepcionales que pudieran surgir, por ejemplo: ?Qué pasa si cuando ya registramos al cliente y a los artículos, el cliente decide cancelar la compra? Bueno, pues deberemos borrar cada uno de los artículos que compró el cliente y al final borrar de la tabla de clientes los datos de ese cliente. Un poco engorroso, ?no? Ahí es cuando las transacciones hacen su aparición. Si hicimos todas nuestras operaciones dentro de una misma transacción, entonces simplemente cancelamos la transacción (rollback) y la base de datos queda como si no hubiera pasado nada. Ahora, si todo sale bien, y el cliente nos paga, entonces confirmamos la transacción y se guardan definitivamente todos los datos que agregamos (datos del cliente, artículos vendidos). Simple y flexible. Una cosa que hay que tener en cuenta es que dentro de una transacción, podemos trabajar como si los cambios se estuvieran aplicando definitivamente, aunque en la realidad (para los demás usuarios de la base de datos) no lo sea. Hay muchos temas relacionados con transacciones, como la actualización de los datos, y errores surgidos de actualizar al mismo tiempo un mismo registro por dos usuarios distintos. Por el momento, y para fines de este artículo introductorio, nos quedaremos hasta aquí. En la próxima entrega explicaré la conexión a una base de datos IB desde Delphi, por medio de los componentes InterBase Express (IBX).