Transacciones. Duda Existencial.

[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.

[Casimiro Notevi]

Empezado por santiago14

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.

Bueno, depende de los componentes que uses, por ejemplo con los IBX puedes indicar un valor por defecto para los casos en que no lo indiques tú mismo y entonces no tienes que hacer nada.
La propiedad "DefaultAction" del componente TIBTransaction.

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

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.

Empezado por santiago14

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.

Que FB lo haga implícitamente es una decisión interna, pero entiendo que a nivel general un usuario no debe usar transacciones para SELECT.
Esto me parece la excepción dentro de los SGBD's. ¿no?

[Casimiro Notevi]

Empezado por Neftali

... entiendo que a nivel general un usuario no debe usar transacciones para SELECT. ...

Por supuesto que no necesita usarlas.