¿Cómo usar mejor las transacciones?

[PedroAlfonso]

Estimado Ferysil:
Yo uso Edits exactamente para lo que tu dices, hacer las transacciones cortas a la hora de modificar o insertar los datos. En mi opinión es lo más seguro y he leído en otros foros a programadores que opinan igual.
No te preocupes por la duración de las transacciones cuando solo lees datos, uno de los motivos más importantes por los cuales existen las transacciones es para modificar varias tablas segun tu proceso, y en caso de error poder deshacer toda la transacción (rollback) para cuidar la integridad de los datos.
Lo recomendable es guardar (modificar) los datos dentro de un Try-except para en caso de falla utilizar el rollback.
Espero haberte ayudado un poco.

[[Crandel]]

Hola ferysil, hay un detalle que me parece que te tiene confundido.

Empezado por ferysil2003

Según veo yo lo más importante es tener claro como usar las transacciones y despues de leer mucho siempre se dice que deben de ser lo más cortas posibles.

Es termino de corta no hace referencia a la duración en tiempo a la cual la transacción esta abierta, sino al tamaño del flujo de datos.

Por ejemplo, si cada vez que modificas tu tabla "Productos", la cual supongamos es muy grande, y grabas la modificación. Este proceso tiene que actualizar la tabla en tu programa, lo cual implica un flujo de datos grande.

Si estas viendo los productos y te paseas todo lo que quieras entre ellos durante un día completo, no hay trafico de datos, se realizo una sola vez cuando te ttrajiste la tabla y luego recorres sobre una copia local.

Espero que aclare.

[ferysil2003]

Gracias PedroAlfonso.
Gracias Grandel.

[1111111]

Yo hago lo mismo que PedroAlfonso.

- Abro transacción.
- Cargo datos en edits o combos.
- Cierro transacción.

Y lo mismo para guardar las modificaciones.

No me fio mucho de las transacciones de Interbase.

[[Crandel]]

Empezado por 1111111

No me fio mucho de las transacciones de Interbase.

por alguna razon en especial?

[Rufus]

Crandel, en sintonía con otros comentarios de este hilo, voy a tener que discrepar un poquito contigo. En la experiencia que pueda tener con firebird te puedo decir que en el rendimiento y seguridad de la base de datos afecta tanto el volumen de traspaso de datos y las características de cada transacción (lectura o escritura, wait o no_wait, nivel de aislamiento) como el tiempo que estén abiertas, sobre todo si son de escritura.

Esto es sencillo de ver: en un entorno multiusuario, si permitimos que las transacciones de escritura sean largas en el tiempo estamos permitiendo la posibilidad de que en un momento dado existan un elevado numero de transacciones de escritura abiertas al mismo tiempo, causando entonces:

• Problemas de concurrencia y consistencia de los datos
• Problemas de rendimiento. La base de datos tiene que soportar un aumento considerable de sus transaction inventory pages, entre otras cosas.
• Tambien aumenta la posibilidad de errores fisicos en la base de datos, esos que tras los cuales hay que ejecutar un gfix o un restore en el peor caso.

Claro que si se trata de una aplicación local para un único usuario los problemas se minimizan bastante.

[1111111]

Empezado por Crandel

por alguna razon en especial?

Antes que nada, aclaro que yo me referia a Interbase, no preste atención cuando decias que usas Firebird, perdón.

En cuanto a Interbase, en lo que no confio es en la perdida de memoria que genera Interbase, por perdida me refiero a que al momento de cerrar una transaccion se deberia liberar la memoria utilizada por la pc local y esto no ocurre. Con el consecuente aumento de la utilizacion de memoria por parte del programa que se esta ejecutando.
De todas formas este problema me parece que lo tienen los componentes IBX, y vos dijiste que usabas otros, asi que no se aplicaria a tu caso este problema.

[[Crandel]]

En prácticamente todos lo programas que he realizado mantengo mis transacciones abiertas (las de uso continuo), y nunca tuve ningún tipo de problemas de concurrencia, consistencia de los datos ni ningún otro.

Los programas si son muchos, aunque ninguno supera los 10 clientes simultaneos.

Pero si hay que tener en cuenta que en un par tengo el servidor corriendo en maquinas con pentium 100 y 120 MHz con 32 Mb de Ram, sin ningún tipo de problema.

[[Crandel]]

Me dejaron pensando en el tema

Supongamos que queremos editar un dato de una tabla y hacelos lo que no sugiere 11111111:

Empezado por 1111111

- Abro transacción.
- Cargo datos en edits o combos.
- Cierro transacción.

Luego modificamos los datos y supongamos que alguien en ese instante más rapido que nosotros los modifica.

Luego nostros al querer actualizar ese registro introduciriamos datos incorrectos poruqe estariamos sobreescribiendo algun valor que el otro usuario puede haber modificado.

Y justamente aqui es donde se produce el problema de consistencia de los datos.

Mi sugerencia es:
* si no confian en el mecanismo de control de concurrencia de su motor de base de datos -> cambien por otro.

Tomen en cuenta que tanto Interbase como Firebird permite definir algunas formas de controlarlo desde nuestra aplicación.

Saludos.

[ferysil2003]

Mi idea de tener abierta una transaccion poco tiempo abierta en tiempo lo digo pensando en lo siguiente: De todos es sabido que lo más difícil de controlar en un programa son los errores que puedan cometer los usuarios que luego usen nuestra aplicación y los cuelgues en los ordanadores. Pensando en esto es por lo que pienso que si un usuario abre una transaccion para modificar un registro, lo estás modificando, tarda cierto tiempo y su ordenador se cuelga (que ocurre), ¿qué pasa con todas esas transacciones que quedan abiertas y nunca se cierran?, pienso que esto puede llevar a problemas.
De todas formas Crandel el problema que planteas de la actualización de dos usuarios a la vez tiene una fácil solución. Se podría poner un campo e incrementarlo con un trigger siempre que se actualice ese registro. Al leer un registro para editarlo, leemos este campo y si cuando mandemos la orden de actualizacion si el valor de este campo no es el que leímos originalmente es porque alguien ha actualizado el registro.

[[Crandel]]

Hola, es verdad que mantener el menor tiempo posible las transacciones abiertas.

ferysil, hace mucho implemente (a medias) una solución como la que comentas cuandro trabajaba con tablas paradox y queria hacerlas multiusuario.

Hoy en dia, todo ese control ya lo realiza el mismo motor.

Aca les dejo un link donde esplica un poco el tema de las transacciones:
http://www.clubdevelopers.com/delphi...fastfb/fb6.php

Con esto no quiero decir que yo lo este haciendo perfectamente, ni lo creo, pero posiblemente con esta discución podamos encontrar una mejor solución para todos y aprendamos más.

Suerte y espero sus comentarios y experiencias.