Hi John,
on second reading of your post,
where/how is the optimistic locking implemented -
if meant in the sense of conflict managment/resolultion -
not talking about simple last write wins g?
Is that something you have implemented for your apps,
similar to the vfp options of timestamp or
Hi John,
I recently scanned the code to get an idea of the changes necessary to
implement
a basic conflict resolution at least on time stamps.
The code to delete back then AFAIR did not check if SQL-delete was
successful.
If my visualization was correct, any rowlock could then probably be
On Monday, October 31, 2011 05:40:25 am Thomas Ganss wrote:
Hi John,
I recently scanned the code to get an idea of the changes necessary to
implement
a basic conflict resolution at least on time stamps.
The code to delete back then AFAIR did not check if SQL-delete was
successful.
If my
John Fabiani schrieb:
Hi Guys,
I like to know the thinking on row locking within the context of the Dabo
framework. We all realize that in some cases it is not desirable to have
optimistic locking (or the MVCC locking of Postgres). For example
shipping/closing a sales order but allowing
On Monday, October 31, 2011 09:43:49 am Vineet Deodhar wrote:
John Fabiani schrieb:
Hi Guys,
I like to know the thinking on row locking within the context of the
Dabo framework. We all realize that in some cases it is not desirable
to have optimistic locking (or the MVCC locking of
Hi Guys,
I like to know the thinking on row locking within the context of the Dabo
framework. We all realize that in some cases it is not desirable to have
optimistic locking (or the MVCC locking of Postgres). For example
shipping/closing a sales order but allowing a second user to modify
