Subject | Re: Urgent help needed: application locks with > 1 user |
---|---|
Author | Adam |
Post date | 2006-10-25T03:56:30Z |
--- In firebird-support@yahoogroups.com, "ione1608" <aiwa1608@...> wrote:
primitive DBMS to actually allow any sort of reporting on a OLTP
system (grabs tin foil hat and dives under table as black helicopters
swarm overhead).
I don't think read uncommitted even works in Firebird, so I am not
sure what your ODBC is doing to simulate it.
I don't use ODBC so I use mostly snapshot (repeatable read) or
occasionally read committed depending on what I am doing.
>Read uncommitted (dirty reads) is even worse. It is a hack used by
> --- In firebird-support@yahoogroups.com, "Adam" <s3057043@> wrote:
> >
> > > I set the AUTOCOMMIT property of the transaction to TRUE and it
> > > works. When the second user wants to open the same record the
> first
> > > user already opened, I give a message that the record is in use
> and
> > > disable the save-functionality. I administer who locks a record
> in a
> > > separate table. This solution works, but how do you pro's
> consider
> > > this? A dirty solution???
> >
> > Absolutely a dirty solution. If it works with AutoCommit (which is
> just
> > an implicit commit then start transaction after each statement is
> run),
> > then it has to be a transaction isolation issue.
> >
>
> Ooopsss, so this is a wrong choice.
> What is the right setting for the isolation level? I tried RU (Read
> uncommitted) and that seemed to work to.
primitive DBMS to actually allow any sort of reporting on a OLTP
system (grabs tin foil hat and dives under table as black helicopters
swarm overhead).
I don't think read uncommitted even works in Firebird, so I am not
sure what your ODBC is doing to simulate it.
I don't use ODBC so I use mostly snapshot (repeatable read) or
occasionally read committed depending on what I am doing.