Before I suggest to Tim I've found a bug can I have other opinions please.

Using tables NOT SQL

I start a transaction, bung data into a couple of tables, go to insert into another ....

dm.DB.StartTransaction([]);
try

 dm.Slips.Insert;
 dm.Slips_Reference.AsString := reference.Text;
 dm.Slips_fkBanks.AsInteger := ToBank;
 dm.Slips_Amount.AsCurrency := Amount.AsFloat;
 dm.Slips_DatePaidIn.AsDateTime := TransferDate.luDate;
 dm.Slips.Post;

this bombs with an error on a unique key - great that's what it should do BUT

except
 dm.DB.Rollback;

and after the rollback dm.Slips is still in insert mode.

Is this the correct behaviour? Or should the rollback cancel the insert?


Roy Lambert

I've just done what I should have done to start with and looked in the manual and it appears that this is correct behaviour.



Note
It is very important that you always ensure that the transaction is rolled back if there is an
exception of any kind during the transaction. This will ensure that the locks held by the transaction
are released and other sessions can continue to update data while the exception is dealt with.
Also, if you roll back a transaction it is always a good idea to refresh any open TEDBTable or
TEDBQuery components linked to the TEDBDatabase component involved in the transaction so
that they reflect the current data and not any data from the transaction that was just rolled back.
Along with refreshing, you should make sure that any pending inserts or edits for the TEDBTable
or TEDBQuery components are cancelled using the Cancel method before the transaction is rolled
back to ensure that the inserts or edits are not accidentally posted using the Post method after the
transaction is rolled back (unless that is specifically what you wish to do).

Weird - I'm off to put a suggestion in.


Roy Lambert

On 9/20/2020 9:48 AM, Roy Lambert wrote:
> I've just done what I should have done to start with and looked in the manual and it appears that this is correct behaviour.
>
....
>
> Weird - I'm off to put a suggestion in.
>

Yes - have run into this as well. Also same in DBISAM (and maybe even in
BDE but not familiar enough with that).

I wonder if this was just a "keep behavior consistent" when migrating to
EDB - when EBD initially came out that likely was a significant
consideration at the time.

In terms of change in EDB to automate this it might be nice to have a
property to control the behavior. Adding new property is not ideal but
only way i can think of ensuring compatibility.

Raul

Raul


>In terms of change in EDB to automate this it might be nice to have a
>property to control the behavior. Adding new property is not ideal but
>only way i can think of ensuring compatibility.

Done it - modified my EDBDatabase subclassed component - dead easy which makes me think I've done something I shouldn't

Roy