--- In IBObjects@yahoogroups.com, "constantijnw" <cw.s@x> wrote:

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

That was my point exactly! I dont care wether the exception comes from
the database or the application.

I was doing a post and commit and now I understand that when committed
the database will not throw an exception when another update that was
read with a earlier recordversion does it's update - and will
therefore possibly do an overwrite.

It's this exact issue the clientdataset resolves by using all the
fields in the dataset and checking wether anything was updated after
it has been executed. I am aware that this is not an database
exception but an application exception but it solves the issue of
owerwriting another users committed changes.

If we all understand each other now :-) (sorry if I was not making my
self clear enough) let me try to ask again :

Does IBO have any means of solving this spesific issue - making sure
that one users committed changes is not overwritten by another users
committed changes? (something like the clientdataset solution)