On 20/06/07, dr_john_mp <dr.john@...> wrote:

> --- In firebird-support@yahoogroups.com, "Nick Upson" <nick.upson@...>
> wrote:
> >
> > On 19/06/07, Svein Erling Tysvær
> > <svein.erling.tysvaer@...> wrote:
> > > --- In firebird-support@yahoogroups.com, "Nick Upson" wrote:
> > > > > Nick Upson wrote:
> >
> > > >
> > > > so I can't let A wait until B commits and then A will proceed?
> > > >
> > > > There isn't actually a conflict as they are updating different
> > > > fields in a single-row table
> > >
> > > If you want to allow these fields to update independantly of each
> > > other and still not allow simultaneous transactions to update the same
> > > field concurrently, I would consider storing them in separate records
> > > or even separate tables.
> > >
> > > Set
> >
> > I was now thinking along those lines as well. Originally there was
> > only 1 process updating this table, then there was a new feature
> > added, don't you love em
> >
>
> We have several applications where different processes, and even
> different applications on different PC's may clash trying to update
> information if the same record. Indeed this is to be expected in lot
> of applications.
>
> To resolve this we always use a construct like

It looks like I will be doing this in a similiar way, with a limited
number of retries if I get that specific error. My remaining headache
is that one of the client applications is isql, which is given a
constructed file of sql statements.