Nico,

if you are using dephi or c++ builder you should take a look at client
datasets, that manage all information in memmory and only open a transaction
when applying the updates. It also controls that the original value you had
is the same that you found on the database before updating (it manages
reconciliation of errors and lets you code what to do in those situations).

if you are not using delphi or c++ builder... just ignore this message
:)

bye!

Luciano.

e-mail lsparacino@...

----- Original Message -----
From: "Nico Callewaert" <nico-callewaert@...>
To: <ib-support@yahoogroups.com>
Sent: Friday, November 22, 2002 11:54 AM
Subject: [ib-support] Re: Transaction question


> Hi Doug,
>
> Thanks for your answer, I was also thinking of something like that
> to build in a mechanism to check things
>
> Thanks for the confirmation !
> Best regards,
> Nico
>
>
> --- In ib-support@y..., Doug Chamberlin <yahoogroups@a...> wrote:
> > At 11/22/2002 09:03 AM (Friday), Nico Callewaert wrote:
> > >User A opens a query and has 1 record displayed on his screen, the
> > >record stays let's say 1 hour on his screen.
> > >In the meantime user B opens the same record, changes it, posts
> the
> > >datset and commits the transaction.
> > >The data on the screen of user A remains unchanged, because there
> > >was no refresh done. Then user A changes the same record, posts
> > >the dataset and commits the transaction.
> > >I suppose the record that user B changed will be overwritten ?
> >
> > It depends on whether user A maintains an open transaction while
> the data
> > is being displayed. It also depends on the transaction isolation
> levels in
> > effect.
> >
> > If user A wants to lock out user B's change then user A will have
> to
> > maintain an open transaction for the whole hour and will have to
> perform an
> > update on the record as soon as it is obtained. Commonly, a dummy
> update is
> > done to lock the record (i.e. UPDATE TABE1 SET FIELD1=FIELD1
> WHERE...).
> >
> > I think for user A to maintain an open transaction for an hour is
> just bad
> > design. Better to design in an application level mechanism for
> user A to
> > detect that user B has changed the record before user A saves
> their
> > changes. In my databases I have a standard field in all tales
> named
> > Revision. It is an integer field which gets incremented by a
> trigger on
> > every insert and update. it is easy for the application to query
> the
> > current revision of the same record before applying an update and
> alert the
> > user that someone else changed the record since they acquired the
> data.
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>