Recent

Author Topic: CachedUpdate  (Read 6950 times)

Medhome

  • New Member
  • *
  • Posts: 12
CachedUpdate
« on: June 30, 2021, 09:01:54 pm »
Hi all,

I use cachedUpdate with master-slave schema . 
Do I have  to applyupdates-commit  current record (master and slave records )  before adding an other master record?

My problem is:

Adding the first master record  and it's slave records  it's Ok
But when I add a second master   the  slave records  disappear  from the grid.?

Did I miss an option?   


tonyw

  • Full Member
  • ***
  • Posts: 229
    • MWA Software
Re: CachedUpdate
« Reply #1 on: July 03, 2021, 01:12:54 pm »
No. That's how it's meant to work. Change the master record and the slave table is cleared and reloaded referencing the new master record. You need  a beforescroll event handler in the master table that applies the cached updates in the slave before the master record changes.

Medhome

  • New Member
  • *
  • Posts: 12
Re: CachedUpdate
« Reply #2 on: July 03, 2021, 11:11:02 pm »
You mean that we have to applyUpdates to  master and  slave before adding a new master record?

Med

tonyw

  • Full Member
  • ***
  • Posts: 229
    • MWA Software
Re: CachedUpdate
« Reply #3 on: July 04, 2021, 12:02:43 am »
You mean that we have to applyUpdates to  master and  slave before adding a new master record?

Med
I would not used cached updates for a master dataset. It is far too easy to get out of sync and get unknown foreign key errors when the updates are applied to the slave.

Cached updates are simply deferred updates that have not yet been applied to a dataset. If you add a new master record but do not write it through to the database and then add records to the slave referencing the new master, you have a problem if the slave records are applied (written to the database) while the master record is stil cached in the client. From the point of view of the database, the records in the slave dataset are referencing a record in the master that does not yet exist.

Why are you using cached updates? Database transactions give you more control, especially in master/slave relationships. If you are using a database such as paradox or an old version of mysql then it is understandable, but if you are using a database with transaction control then I would recommend using transactions instead of cached updates.

korba812

  • Full Member
  • ***
  • Posts: 198
Re: CachedUpdate
« Reply #4 on: July 04, 2021, 11:09:27 am »
I would not used cached updates for a master dataset. It is far too easy to get out of sync and get unknown foreign key errors when the updates are applied to the slave.
There is nothing wrong with using CachedUpdates as long as you do it correctly. I am using Rollback transaction only in case of error while saving changes to database. I have been using this for years and am happy with it, even with Master-Detail. You just need to follow the order in which to commit changes to datasets.

tonyw

  • Full Member
  • ***
  • Posts: 229
    • MWA Software
Re: CachedUpdate
« Reply #5 on: July 04, 2021, 01:15:24 pm »
There is nothing wrong with using CachedUpdates as long as you do it correctly.
i suppose that all high risk activities are safe "as long as you do them correctly'.

My point is that it is not necessarily easy to always apply updates in the correct order unless you take a great deal of care - especially in an event driven program. Hence, my view that cached updates need a "handle with care" sticker on them. And this is before you get on to:

- Database validation checks. You can get into a mess if your database applies unexepected validation checks when you come to save your updates and aborts your update half way through.

Once your program has passed a certainly level of complexity then I would always recommend writing updates to a database as soon as they occur and using transaction management to cancel changes at the end of a dialog. You avoid so many problems this way.

- Multi-user conflicts. You may only find out about conflicting updates when you save your updates.

korba812

  • Full Member
  • ***
  • Posts: 198
Re: CachedUpdate
« Reply #6 on: July 04, 2021, 03:31:48 pm »
I didt say that CachedUpdates replaces transaction management. Using CachedUpdates does not exclude data validation before update.

I believe that using long-term transactions is not the best solution - if you are using a blocking transaction, some resources will be unavailable for other transactions, but if you use non-blocking transactions, anyway you need to validate the data before committing the transaction (data that could be changed by other transactions, checked on the client or server side).
My policy is to make updates as atomic as possible.

Medhome

  • New Member
  • *
  • Posts: 12
Re: CachedUpdate
« Reply #7 on: July 07, 2021, 12:40:06 pm »
the Event tfield onChange is  fired when we update a record but not fired when we reset  it
( ex cancelUpdate or simply cancel ) . Can we change this behavior?   

devEric69

  • Hero Member
  • *****
  • Posts: 614
Re: CachedUpdate
« Reply #8 on: July 07, 2021, 02:13:24 pm »
AFAIK, (if you can't code in TDBdataset's BeforeCancel or AfterCancel, with CachedUpdate enabled) you can try TDBNavigator's events too, like: StateChange(DataSource1), DataChange(DataSource1, nil).
« Last Edit: July 07, 2021, 02:15:20 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Medhome

  • New Member
  • *
  • Posts: 12
Re: CachedUpdate
« Reply #9 on: July 07, 2021, 03:03:09 pm »
tfield.changed is fired when tfield.value <> tfield.oldvalue ?  That what I expected?

devEric69

  • Hero Member
  • *****
  • Posts: 614
Re: CachedUpdate
« Reply #10 on: July 07, 2021, 03:18:26 pm »
AFAIK, TField.OnChange is normaly only fired when we code "aField.Asxxx:= ..." (without CachedUpdate). So, without CachedUpdate, if you Cancel afterwards  "aField.Asxxx:= ...", called in one way or another, this event will not be fired. In other words, what you observe - with CachedUpdate enabled - doesn't surprise me at all.

A normal Cancel can be seen as a [ Rollback + Refresh SQL statement ]. With the CachedUpdate layer (=~ fake temporary database, buffered on client side, over\before TDataset itself), a CancelUpdate should be coded using another new memory buffer (CachedUpdate = " briefcase \ travel-case model ", a kind of " offline database pattern ") on top, over the TDataset and its layer of TFields (really connected, ultimately through a TUpdateSQL polymorphism and its Apply methods, to the real database).
« Last Edit: July 07, 2021, 06:15:03 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Medhome

  • New Member
  • *
  • Posts: 12
Re: CachedUpdate
« Reply #11 on: July 09, 2021, 06:46:19 pm »
There is neither BeforeCancelUpdates nor AfterCancelUpdates  to cancel other tasks we did afterpost a record ?

 

TinyPortal © 2005-2018