Problema con excepciones con ClientDataSet

[[David]]

Hola

Tengo una función que devuelve un valor true o false , si se han podido o no grabar los datos .

Esto con Firebird , y tengo una TIBQuery , asociado el provider y el TClientDataSet y un componente TIBUpdateSQL para actualizar.

La tengo códificada algo así :

Código Delphi [-]
// Inicializo el resultado
Result := True;
// La funcion

// hago la inseción con el clientDataSet

// Hago el post
miClientDataSet.post;

miClientDataSet.ApplyUpdates(0);

Try
  IBTransaction1.Commit;
Except
  IBTransaction1.Rollback;
  Result := False;
end;

Pues bien , cuando me da una excepcion al pasar por miClientDataSet.ApplyUpdates(0); , no me entra en el Except y me devuelve True , en lugar de False y luego pues no puedo mostrar un mensaje al usuario , que saldria obviamente , cuando la función devuelva False y no True.

¿Qué es lo que falla en el código ?

Cómo deberia de poner dicha excepción ??


Un saludo

[[egostar]]

Hola David

Yo pienso que así estaría bien.

Código Delphi [-]
Result := True;
Try
  miClientDataSet.post;
  miClientDataSet.ApplyUpdates(0);
  IBTransaction1.Commit;
Except
  IBTransaction1.Rollback;
  Result := False;
end;

Salud OS

[[Chris]]

Solo cuando salga todo correcto es que el resultado debe ser true

Código Delphi [-]
Result := False;  // nunca sabemos que puede pasar.
Try
  miClientDataSet.post;
  miClientDataSet.ApplyUpdates(0);
  IBTransaction1.Commit;
  Result := True;  // todo ha salido bien
Except
  IBTransaction1.Rollback;
end;

[[David]]

Digo yo , el post , tiene que estar dentro de la excepción ?

por que podria estar dentro de un bucle , algo así :

Código Delphi [-]
Result := False;

while not ClientDataSet.eof do
begin
 ClientDataSet.Insert;
 // asignaciones correspondientes
 ClientDataSet.post;
 ClientDataSet.Next;
end;

//
try
ClientDataSet.ApplyUpdates(0);
Transaction1.Commit;
Result := True;
except
Transaction1.Rollback;
end;

Es decir , como habeis dicho , pero el post lo dejo fuera del Try . Por si tuviera el caso de un bucle , que no es el caso que tengo ahora , pero me parece que tengos otros casos así.

Un saludo

[[basti]]

ApplyUpdates no genera ninguna excepcion, devuelve el número de errores al actualizar los datos.

Código Delphi [-]
  if ClientDataSet.ApplyUpdates(0) > 0 then
  begin
    // entra aquí si hay errores
  end
  else begin
    // entra aquí si no hay errores
  end;

[[Al González]]

¡Hola a todos!

Basti: ApplyUpdates sí genera excepciones pero las canaliza todas al evento OnReconcileError. Es ahí donde David puede mostrar el mensaje al usuario.

Darwin: El código de Eliseo (Egostar) tendrá exactamente los mismos resultados que el tuyo, aunque quedaría mejor así:

Código Delphi [-]
  miClientDataSet.Post;
  
  If miClientDataSet.ApplyUpdates (0) = 0 Then
  Begin
    IBTransaction1.Commit;
    Result := True;  // El registro se aplicó sin problemas
  End
  Else
  Begin
    IBTransaction1.Rollback;
    Result := False;  // Algo salió mal al intentar aplicar el registro
  End;

Un abrazo cometido.

Al González.

[[basti]]

Empezado por Al González

ApplyUpdates sí genera excepciones pero las canaliza todas al evento OnReconcileError.

No estoy de todo de acuerdo con eso. ApplyUpdates gestiona los posibles errores a través de OnReconcileError, pero no genera ninguna excepción.

Código Delphi [-]
  try
    ClientDataSet.ApplyUpdates(0);
  except
    // Aquí no entraría nunca, haya o no haya errores.
  end;

[[David]]

El caso es que la estructura del programa es algo así , con ClientDataSet de detalle .

Código Delphi [-]
// inserto los datos en un ClientDataSet , por ejemplo Client1
Client1.post.

// compruebo si el detalle tiene datos

if not ClientDetalle.isEmpty then
begin
 while not ClientDetalle.eof do
  begin
    // inserto los registros
     ClientDetalle.post;
 end;
end;

// Después haria supongo esto

if (Client1.ApplyUpdates(0) = 0) and (ClientDetalle.ApplyUpdate(0)=0) then
begin
 Commit;
 Result := True;
end
else
begin
 Rollback;
 Result := False;
end;

Bueno , pues eso , ya para poner el código definitivo , me gustaria saber si lo anterior por lo que habeis comentado es ya lo correcto.

[[pepon386]]

Una cosa, cuando haces esto:

Código Delphi [-]
if (Client1.ApplyUpdates(0) = 0) and (ClientDetalle.ApplyUpdate(0)=0) then
begin
 Commit; <-------------
 Result := True;
end
else
begin
 Rollback; <--------------
 Result := False;
end;

si mal no recuerdo, al llamar a ApplyUpdates, en este método inicia una transacción, realiza los cambios que hay pendientes en el Delta del ClientDataSet y, si todo ha ido bien, efectúa el Commit de la transacción. En caso contrario, si se ha quedado algún error (no ha sido gestionado en el evento OnReconcileError) entonces hace un Rollback de la transacción.
Repito que escribo de memoria, pero más o menos es así, con lo que el Commit y Rollback del ejemplo sobran.

[[Al González]]

¡Hola a todos!

Empezado por Al González

...ApplyUpdates sí genera excepciones pero las canaliza todas al evento OnReconcileError...

Empezado por basti

No estoy de todo de acuerdo con eso. ApplyUpdates gestiona los posibles errores a través de OnReconcileError, pero no genera ninguna excepción...

Aquí la sentencia donde, a través del método ReconcileCallback, ApplyUpdates genera (crea) las excepciones relacionadas con problemas al aplicar los datos (línea 1833 de DBClient.pas en Delphi 7):

Código Delphi [-]
    E := EReconcileError.Create(pErrMessage, pErrContext, iErrCode, iRslt);

Ciertamente no eleva (Raise) tal excepción, pero si envía el objeto como parámetro al evento OnReconcileError (línea 1850):

Código Delphi [-]
        FOnReconcileError(DataSet, E, UpdateKind, Action);

Por lo tanto es correcto que tal excepción no sale elevada fuera del método ApplyUpdates, como bien lo ilustras en este código donde me permití agregar una línea al comentario:

Empezado por basti

...

Código Delphi [-]
  try
    ClientDataSet.ApplyUpdates(0);
  except
    // Aquí no entraría nunca, haya o no haya errores
    // —de los que crea ReconcileCallback—.
  end;

En concluyente pues, que de nada sirve usar un bloque Try-Except para atrapar las excepciones de clase EReconcileError, puesto que éstas no son elevadas. Por otra parte, la recomendación que hago de usar If sobre ApplyUpdates presenta un par de detalles interesantes cuando se considera algo como esto:

Empezado por pepon386

Una cosa, cuando haces esto:

Código Delphi [-]
if (Client1.ApplyUpdates(0) = 0) and (ClientDetalle.ApplyUpdates(0)=0) then
begin
 Commit; <-------------
 Result := True;
end
else
begin
 Rollback; <--------------
 Result := False;
end;

si mal no recuerdo, al llamar a ApplyUpdates, en este método inicia una transacción, realiza los cambios que hay pendientes en el Delta del ClientDataSet y, si todo ha ido bien, efectúa el Commit de la transacción. En caso contrario, si se ha quedado algún error (no ha sido gestionado en el evento OnReconcileError) entonces hace un Rollback de la transacción.
Repito que escribo de memoria, pero más o menos es así, con lo que el Commit y Rollback del ejemplo sobran.

Lo que dice Pepon386 es hasta cierto punto verdadero, digo esto porque depende del componente proveedor utilizado y de si la conexión ya está dentro de una transacción o no. Es el componente TDataSetProvider, en su método InternalApplyUpdates (línea 2618 de Provider.pas en Delphi 7), quien maneja el guardado de los datos de manera transaccional (inicia transacción, aplica los datos y comete la transacción o bien la revierte si ocurre un problema). Pero sólo lo hace si la conexión a la base de datos no está ya dentro de una transacción.

Dejar que el proveedor maneje la transacción no es útil cuando queremos involucrar dos o más conjuntos de datos clientes en una sola transacción, como es el caso actual de David, donde hace bien en iniciar él mismo la transacción de manera explícita. Sin embargo esta útil opción tiene un precio incómodo:

Si Client1.ApplyUpdates(0) devuelve 0 y ClientDetalle.ApplyUpdates(0) no, es claro que la transacción ha de ser revertida (Rollback) en el Else. Pero Client1 se quedará con la idea de que los datos aplicados siguen vigentes (su propiedad ChangeCount habrá sido restablecida a 0). Esto obliga a emplear un Client1.Refresh o algún mecanismo similar para reubicar a Client1 en la realidad; y si lo utilizado para ello fue una llamada al método Refresh, ¿qué pasa con lo que ya se había asignado al registro? A menos que algo se me escape, tales datos se pierden.

Claro, siempre será posible conservar una copia de los datos en alguna variable o algo por el estilo (incluso esto puede convertirse en un pretexto más para los dataawarefóbicos), finalmente Delphi, a diferencia de otros lenguajes, tiene solución para todo.

Como comentario extra, hace tiempo vengo agregando nuevas características a derivados de TClientDataSet, TDataSetProvider y otros componentes de acceso a datos. Actualmente trabajo en un mecanismo que permitirá conservar la propiedad ChangeCount aún después de haber hecho un ApplyUpdates exitoso, esto con el fin de manejar varios conjuntos de datos clientes en el contexto de una transacción del servidor de manera más sencilla y consistente.

Un abrazo transaccional.

Al González.