Transacciones. Duda Existencial.

[usuario1000]

Hola a todos.

Estoy realizando una aplicación en Delphi con FireDac (cliente - Servidor[ Base de datos FireBird 2.5]), decir que es la primera vez que hago este tipo de aplicaciones, y ya llevo creado bastante código y probado con las tablas de la base de datos que funcionan bien, pero no utilizo las transacciones. ¿es necesario utilzarlas?. Se supone que la aplicación trabajará en una red Local. Sobre las tablas hago todo tipo de operaciones, insertar, consultar, eliminar, modificar.

Necesitaría un poco de luz, para no tener que reescribir todo el codigo que tengo ya terminado.

Saludos y gracias.

[Neftali [Germán.Estévez]]

Bueno la respuesta no es que SI ni que NO.
Es depende de si las necesitas...

Para saber si las necesitas primero debes tener claro qué es una transacción y para qué se usa.
Si te encuentras en ese caso, la necesitas, si no te encuentras en ese caso, no la necesitas.

Ejemplo más común, que seguramente aparecerá en tu aplicación:
Tienes registros de una tabla relacionados con otra (maestro/detalle) o una relación 1-1.
De forma que al hacer una inserción se deben insertar los datos de las dos tablas o de ninguna; Podría pasar que los registros de la primera se inserten correctamente, pero al insertar los de las segunda se produzca un error y estos no lleguen a insertarse.
Te quedaría la cosa "a medias", por decirlo así.
Eso se arregla con una transacción que englobe las 2 operaciones.

[mamcx]

Empezado por usuario1000

pero no utilizo las transacciones. ¿es necesario utilzarlas?.

Deberias estudiar sobre SQL y bases de datos relacionales. Son herramientas muy versatiles y poderosas, que son altamente INFRA-VALORADAS y sub-utilizadas.

Y si, necesitas transacciones. De hecho, usas transacciones sepas o no.

[santiago14]

Totalmente sí. Debes usar las transacciones, inclusive para las Consultas (Select...)

Una estructura muy usada y bastante buena en Delphi es: (Suponiendo que ya estás conectado y todo eso)

Código Delphi [-]
    try
      transaccion.StartTransaction;
      nuevo_cliente(cliente, consulta); //Este es un Insert
      transaccion.Commit;
      application.MessageBox('Cliente ingresado con éxito.',
        'Clientes', MB_OK + MB_ICONINFORMATION);
    except
      on E:Exception do
      begin
        transaccion.Rollback;
        application.MessageBox('No se pudo dar de alta al cliente. ' + e.Message,
        'Clientes', MB_OK + MB_ICONINFORMATION);
      end;
    end;

Funciona bastante bien y se acaban la mayoría de los problemas.
Recordar, siempre hacer las operaciones contra la BBDD en una transacción. SIEMPRE.

Santiago.

[[AgustinOrtu]]

El StartTransaction debe ir fuera del bloque try; ya que si no puede iniciarse la transaccion, no podras hacer el Rollback

La documentacion de Embarcadero recomienda hacerlo de esta manera:

Código Delphi [-]
FDConnection1.StartTransaction;
try
  FDQuery1.ExecSQL;
  ....
  FDQuery1.ExecSQL;
  FDConnection1.Commit;
except
  FDConnection1.Rollback;
  raise;
end;

Se puede reemplazar el FDConnection por un componente de Transaction, no hay problema.

[[AgustinOrtu]]

Empezado por santiago14

Totalmente sí. Debes usar las transacciones, inclusive para las Consultas (Select...)

Por otra parte, porque utilizar una Transaccion para lecturas? Excepto en casos en los que explicitamente se desee bloquear al resto para que no puedan actualizar hasta que la aplicacion termine de consumir esos datos; pero en general todos deberian poder leer sin bloquear al resto

[Casimiro Notevi]

Yo no suelo hacerlo implícitamente, sino que dejo a los componentes que se encarguen ellos automáticamente, incluyo en un datamodule principal un componente de bases de datos y otro de transacciones, ambos enlazados entre sí y me despreocupo de mantener yo las transacciones.
Vista en texto sería esto:

object DB1: TIBDatabase');
  DatabaseName = ''localhost:192.168.1.100:\datos\unabasededatos.fdb''' );
  Params.Strings = (');
    ''user_name=SYSDBA''');
    ''password=masterkey''');
    ''lc_ctype=ISO8859_1'')');
  LoginPrompt = False');
  DefaultTransaction = TR1');
  SQLDialect = 3');
  Left = 157');
  Top = 56');
end');
object TR1: TIBTransaction');
  DefaultDatabase = DB1');
  Params.Strings = (');
    ''read_committed''');
    ''rec_version''');
    ''nowait'')');
  Left = 218');
  Top = 56');
end');

[Neftali [Germán.Estévez]]

Empezado por santiago14

Debes usar las transacciones, inclusive para las Consultas (Select...)

¿Hay alguna razón para utilizar las consultas en SELECT? Tal vez se me escapa, pero a primeras yo tampoco le veo sentido...
Vas a sobrecargar el sistema con una lógica que no necesita y a la que no le vas a sacar ningún rendimiento.

[Casimiro Notevi]

Empezado por Neftali

¿Hay alguna razón para utilizar las consultas en SELECT? Tal vez se me escapa, pero a primeras yo tampoco le veo sentido...
Vas a sobrecargar el sistema con una lógica que no necesita y a la que no le vas a sacar ningún rendimiento.

Por ejemplo un select "gordo" que tarda unos segundos y mientras tanto están insertando nuevos registros, o borrándolos, en otros terminales.

De forma predeterminada, firebird usa transacciones siempre, incluso select. No hay que llamarlas implícitamente.

[santiago14]

Empezado por Casimiro Notevi

Por ejemplo un select "gordo" que tarda unos segundos y mientras tanto están insertando nuevos registros, o borrándolos, en otros terminales.

De forma predeterminada, firebird usa transacciones siempre, incluso select. No hay que llamarlas implícitamente.

Y sí. Firebird hace de manera automática la transacción. Por lo cual, al final de tu consulta deberías hacer un Commit, o un Rollback.