Subject | Re: Forcing closure of client transactions |
---|---|
Author | Adam |
Post date | 2007-04-24T02:21:32Z |
--- In firebird-support@yahoogroups.com, "robertgilland"
<robert_gilland@...> wrote:
The words baby and bathwater spring to mind.
You really need to design your application and database to not hold
updates indefinitely. If you don't, you really are at the mercy of
your users causing the commit to happen. When you design, build into
it the fact that they are going to leave a screen open while they go
to lunch, or trip over the power cable which Firebird doesn't deal
with for a few hours.
What this means in practice is to not leave uncommitted updates just
lying around, especially in tables where you have multiple users
performing actions.
Adam
<robert_gilland@...> wrote:
>Robert,
> How can we tell then that there will not be an update conflict,
> before we start a process?
>
> Kind Regards,
>
>
> Robert.
The words baby and bathwater spring to mind.
You really need to design your application and database to not hold
updates indefinitely. If you don't, you really are at the mercy of
your users causing the commit to happen. When you design, build into
it the fact that they are going to leave a screen open while they go
to lunch, or trip over the power cable which Firebird doesn't deal
with for a few hours.
What this means in practice is to not leave uncommitted updates just
lying around, especially in tables where you have multiple users
performing actions.
Adam