Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 4 of 4 total |
Transaction, rollback & table state |
Sun, Sep 20 2020 9:40 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sun, Sep 20 2020 9:48 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sun, Sep 20 2020 10:56 AM | Permanent Link |
Raul Team Elevate | 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 |
Mon, Sep 21 2020 5:43 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |