Subject | Re: [ib-support] Re: Crossed signals? |
---|---|
Author | Claudio Valderrama C. |
Post date | 2002-03-27T10:02:50Z |
"Helen Borrie" <helebor@...> wrote in message
news:5.1.0.14.0.20020327094422.069a4da0@......
mode if you don't do anything about it. In that scenario, A does
update t set f1 = v
where key = 5;
and its txn is committed immediately.
Then B does
update t set f2 = v2
where key = 5;
and its txn is committed immediately.
In this scenario, neither the engine nor the BDE are wrong. It's simply the
effect of two operations that don't conflict because their transactions
don't collide, so the engine cannot detect the mixture.
with another one. This doesn't happen with the BDE in default txn mode. This
is why the default was UpWhereAll, so all fields are checked when updating.
This is a problem that the user needs to decide how to solve.
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing
news:5.1.0.14.0.20020327094422.069a4da0@......
> At 04:48 PM 26-03-02 -0500, Louis Kleiman wrote:keyvalue
> >If you are using the BDE, then turn on SQL Monitor and see what UPDATE
> >statements are being sent by each client. The BDE will only update the
> >fields that were actually changed by each client. So, if User A changes
> >first name, and User B changes last name, then it is extremely possible
> >that both updates will make it into the record because User A's UPDATE
> >looks like:
> > UPDATE table set FirstName = 'UserAFirstName' WHERE keyfield =
> >and User B's UPDATE looks likeLouis explanation is perfectly possible: the BDE usually works in autocommit
> > UPDATE table set LastName = 'UserBLastName' WHERE keyfield = keyvalue
>
> Well, it's an interesting proposition but it's completely false. Updates
> in Firebird and IB happen at row level. UpdateWhereAll, etc., affect the
> SQL that is sent across the wire by the client, but they don't change the
> architecture of the database! The BDE doesn't magically somehow allow two
> transactions to update the same version of a row because they happen to be
> modifying different columns.
mode if you don't do anything about it. In that scenario, A does
update t set f1 = v
where key = 5;
and its txn is committed immediately.
Then B does
update t set f2 = v2
where key = 5;
and its txn is committed immediately.
In this scenario, neither the engine nor the BDE are wrong. It's simply the
effect of two operations that don't conflict because their transactions
don't collide, so the engine cannot detect the mixture.
> As soon as one transaction requests an update on version n of a row, anyyour
> other transaction will be unable to update that version of the row, so
> proposition is absurd.You are assuming a model where a transaction lasts enough to have a conflict
with another one. This doesn't happen with the BDE in default txn mode. This
is why the default was UpWhereAll, so all fields are checked when updating.
This is a problem that the user needs to decide how to solve.
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing