--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> At 01:03 PM 2/07/2004 +0000, you wrote:
> >I'm sorry - I'm still a bit confused. I tried to set the properties on
> >the transaction as you suggested.
> >
> >Isolation = tiCommitted
> >RecVersion = False
> >LockWait = False
> >
> >
> >I then started my app twice, found the same record in both instances
> >and first did an update in the first app and save. Then i went to
> >second app instance and did another update here on the same record and
> >field and when I saved I did a overwrite of my first change and got no
> >exceptions.
> >
> >If I understand you right this should be impossible with these
> >settings.
>
> By "Save" do you mean "Post and Commit"? You can never prevent

overwriting

> of others' work once it is committed, if your transaction is newer

than the

> one that committed the work.
>
>
> >A part of this app use Clientdatasets and they use all fields in the
> >where part of the update statement and they actually capture this
> >problem - that's why I asked wether it was possible to make the IBO
> >components do the same.
> >
> >I think :-) I understand why IB/FB (and therefore IBO) shouldent
> >actually need this, as the architecture of the database (with
> >recversion's) should handle this - it just dosen't seem to work - or I
> >at least can't seem to get it working - or am I still not getting it??
> >:-)
>
> I think what you are not getting is that work that is posted but not
> committed is protected. Committed work is always available for a new
> transaction to update.
>
> And, whatever you believe a clientdataset can do, it can NOT do a

partial

> update on any record in InterBase or Firebird - EVER. The database
> implementation of transaction isolation rules - no interface can

change that.

Perhaps confusing is that Jens wrote about getting exceptions from
FB/IB when user B changed a record that user A read before, editted
it and post/commit it after user B's change.
The exception is not raised by FB/IB but by the application that
checks if the DML statement actually affected any rows (by reading the
RowsAffected) property. That DML statement will not affect any rows
when its where clause contains conditions that retrieve the original
record first before updating it.