CachedUpdate

[Medhome]

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]

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]

You mean that we have to applyUpdates to  master and  slave before adding a new master record?

Med

[tonyw]

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]

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]

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]

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]

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]

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).

[Medhome]

tfield.changed is fired when tfield.value <> tfield.oldvalue ?  That what I expected?

[devEric69]

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).

[Medhome]

There is neither BeforeCancelUpdates nor AfterCancelUpdates  to cancel other tasks we did afterpost a record ?