Here is the code that is not working right:

begin
  Database.StartTransaction;
  try
     with FormSearch do begin
        Patients.Open;
        Patients.Insert(True);
        Patients.Columns['MRN'].AsString:=EditMRN.Text; // I enter a duplicate primary key to force a commit error
        Patients.Save;
     end;
     Database.Commit;
  except
     ShowMessage('Error!');  <= never shown despite a commit error
     Database.Rollback;
     raise;
  end;
end;

So I enter a duplicate primary key and I do get an error message dialog:

-------------------------------------------------------
Application Error

Database commit response error: ElevateDB Error #1004 The
primary key constraint UniqueID for the table Patients has been
violated (Duplicate key 12345677 found)
--------------------------------------------------------

The above error msg is correct. However, an exception is not raised and the Transaction is still active after the commit. I am not using an OnCommitError event handler.

I am using latest version of EWB and ElevateDB. I am using EDB in local mode in the IDE.

My understanding is that if the OnCommitError event handler is not used, then an exception should be raised. Is this not correct?

Thanks for any help,
David Martin

On 9/4/2013 10:46 PM, David Martin wrote:
> The above error msg is correct. However, an exception is not raised and the Transaction is still active after the commit. I am not using an OnCommitError event handler.

EWB is asynchronous so you need to use OnCommitError and cannot catch
this type of exception with the code shown.

> My understanding is that if the OnCommitError event handler is not used, then an exception should be raised. Is this not correct?

The documentation is correct as well - exception is raised (and you're
seeing it)  but not as a direct result of the Commit call  - since it's
async there is no way to call it there - but as a result of the commit
completion (after response is received from web server) and there not
being a OnCommitError.

It's likely an application level exception since you never assigned
OnCommitError - you could in theory handle this in Application OnError
but OnCommitError is really what you should be using.


Raul

Raul,

This is from the documentation:

The following example starts a transaction, deletes all rows, and then commits the transaction. It uses a try..except code block to ensure that the transaction is either committed or rolled back:

begin
  Database.StartTransaction;
  with Products do
     begin
     while (RowCount > 0) do
        Delete;
     end;
  Database.Commit;
end;

-----

OK, the example does not fit the description because there is no try...except block and there is no call to Rollback. Nevertheless, if what you say is correct then the above documentation must be wrong. Needless to say, I am confused.

DM

On 9/5/2013 8:51 PM, David Martin wrote:
> Nevertheless, if what you say is correct then the above documentation must be wrong. Needless to say, I am confused.

The sample you listed is definitely missing try except and rollback so
that part is wrong.

Anyways, if you read rest of the section in manual you'll see that it is
covered there so it's a matter of not being very clear.

1. Commit itself can throw an exception - for example if database is
currently not in a transaction. This one would be captured by your
original code. You would not be able to capture a back end exception
like key violation though this way.

2. It also says "If the current transaction level, as reflected by the
TDatabase TransactionLevel property, is 0, create a web server POST
request and send it to the web server application, with the transaction
data included as the POST content in JSON format. If the web server POST
request is not successful due to an exception or the web server
application returning an HTTP result code other than 200 (OK), the
OnCommitError event will be fired and will include the error message. If
an event handler is not defined for the OnCommitError event, then an
exception will be raised with the error message."

This is asynchronous by definition (see manual for Server Request
Architecture) if you don't believe me.

This section also again says you should use OnCommitError.

Anyways, i'm not asking you to believe me - just try it out.

In general always assume async operation with EWB so you will need to
rely on callback functions and such.


Raul

David,

<< The following example starts a transaction, deletes all rows, and then
commits the transaction. It uses a try..except code block to ensure that the
transaction is either committed or rolled back: >>

This has been corrected.  Some of the earlier documentation regarding
transactions was incorrect, and I updated the example without fixing the
description.

Tim Young
Elevate Software
www.elevatesoft.com