At 06:02 AM 27-03-02 -0400, Claudio wrote:

>"Helen Borrie" <helebor@...> wrote
> >
> > 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.
>
>Louis explanation is perfectly possible: the BDE usually works in autocommit
>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.

Exactly so, but this is not what Louis' statement claimed. He claimed that
the BDE updates only individual columns and implied that two transactions
could update the same row simultaneously. Here's what he said:

<< 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 =
keyvalue
and User B's UPDATE looks like
UPDATE table set LastName = 'UserBLastName' WHERE keyfield = keyvalue >>

This gives the impression that the BDE is somehow capable of merging the
updates from two different transactions into a single record. It can't
happen and the BDE can't make it happen.

>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.

So let's ALL be clear: a BDE update updates a row, and modifies those
columns it needs to modify. Whether or not a conflict occurs when first
one and then another transaction update the "same" record (i.e. the row
with the same key) depends on transaction isolation and record_version, the
fact that a conflict doesn't occur is not an indication of misbehaviour by
the engine.

At the end of the day, I believe we might all have *intended* to say the
same thing...

Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________