Forum > Databases


<< < (2/3) > >>


--- Quote from: korba812 on July 04, 2021, 11:09:27 am ---There is nothing wrong with using CachedUpdates as long as you do it correctly.

--- End quote ---
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.

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.

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?   

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

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


[0] Message Index

[#] Next page

[*] Previous page

Go to full version