Subject | Re: [IBO] IBOQuery with record locking |
---|---|
Author | earnesttse |
Post date | 2008-03-20T04:43:58Z |
Dear Jason,
As I know, if one user edited and posted a record in a transaction,
beofore the user to commit the transaction, other user can see the
latest commited version of record, right?
My problem is that in this case the secord can't be read or opened by
other user. The second user want to read the record only, not to edit
or delete. When the second user to read the record, IBO raise a
record lock conflict error.
I tried this:
1. User A: StartTransaction -> Insert one master record or one detial
record -> post both master and detail record -> comit the transaction
2. User B can read about records.
3. User A: StartTransaction -> edit master record -> edit detail
record and post it
4. User B: open IBOQuery of master table without problem
5. User B: open IBOQuery of detail table -> this IBOQuery can't be
open untill User A call commit or rollback
I found that the system stoped at line 6321 of IBODataset.pas:
InternalDataset.BufferRowNum := FCurRowNum + 1; After User A call
commit or rollback, the system will run again.
My question is: why the code (InternalDataset.BufferRowNum :=
FCurRowNum + 1;) causes record locking conflict?
Thanks for help!
Earnest
--- In IBObjects@yahoogroups.com, "Jason Wharton" <supportlist@...>
wrote:
As I know, if one user edited and posted a record in a transaction,
beofore the user to commit the transaction, other user can see the
latest commited version of record, right?
My problem is that in this case the secord can't be read or opened by
other user. The second user want to read the record only, not to edit
or delete. When the second user to read the record, IBO raise a
record lock conflict error.
I tried this:
1. User A: StartTransaction -> Insert one master record or one detial
record -> post both master and detail record -> comit the transaction
2. User B can read about records.
3. User A: StartTransaction -> edit master record -> edit detail
record and post it
4. User B: open IBOQuery of master table without problem
5. User B: open IBOQuery of detail table -> this IBOQuery can't be
open untill User A call commit or rollback
I found that the system stoped at line 6321 of IBODataset.pas:
InternalDataset.BufferRowNum := FCurRowNum + 1; After User A call
commit or rollback, the system will run again.
My question is: why the code (InternalDataset.BufferRowNum :=
FCurRowNum + 1;) causes record locking conflict?
Thanks for help!
Earnest
--- In IBObjects@yahoogroups.com, "Jason Wharton" <supportlist@...>
wrote:
>user then
> It sounds like what you are asking for is a dirty read.
> This is not something that InterBase or Firebird allows.
> This is also something that is not desirable.
> If you want another user to be able to see changes from another
> they have to be committed and in a tiCommitted isolation.On
>
> Jason Wharton
>
> > -----Original Message-----
> > From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
> > Behalf Of earnesttseedited
> > Sent: Wednesday, March 19, 2008 7:01 PM
> > To: IBObjects@yahoogroups.com
> > Subject: [IBO] IBOQuery with record locking
> >
> >
> > Hello, I have a record locking problem needing your help!
> >
> > I have master/detail tables to record sale invoice. I call
> > IB_Database.StatTransaction before editing master reocrd. When one
> > user is editing a record of detial, other user can't read the
> > record, system will wait until the record has been cancelled orrecord
> > posted.
> >
> > Is there any way to allow the second user to view the edited
> > without waiting the first user completed editing?transaction
> >
> > I read the book of Helen: The Firebird Book. I found that in page
> > 552: In Firebird, all updates are at row level ... When a
> > submits a request to update a row; the old version of that row
> > remains visible to all transactions. Writers do not block readers.
> >
> > Is there anything I missed?
> >
> > I am using Delphi 2007, IBO 4.8.7, IBOQuery, AutoCommit=True,
> > Isolation=tiCommitted.
> >
> > Your prompt reply is highly appreciated!
> > Thanks for help!
> >
> >
> > Earnest
>