Re: Re: DB_DataObjects save method

Hundiak, Arthur wrote:

A nice option would to have the UPDATE operation first do a SELECT and then only update the record if something has actually changed. The idea is that a select is generally faster than an update so performance can be improved by avoiding unnecessary updates. Of course it has to be optional since sometimes you know for certain the record has changed. Yes, but in case you are not alone working on the database:

what it is if the change where commited by another user or machine ? That could reset the data to old value ! In fact, when you serve some data to be updated to user, blocking the data doesn't work because it can be needed elsewhere The schema used on some industrial applications I know with high concurence between PLA and humans works fine: Save data as it's delivered to client When update come back from client: Open a transaction Read the data (with for update clause to block other access to it) again Check against the save if it was not changed since it was delivered to the client If changed refuse the update, send back to client If still the same make the changes commit transaction It's a common schema. Such way of protecting from double access could be really of value. bye bertrand Gugger (toggg)