Well, the basic error message is (and only after them the bugcheck
messages come, so - I hope if I manage to eliminate these, then the
bugcheck messages would be eliminated well):
'lock conflict on no wait transaction
deadlock
update conflicts with concurrent update'

And it can be fairly simply reproduced: user A updates record 1 and
then user B tries to update the same record 1 and so - user B
receives this error message, however, user A can continue his work on
record 1 how long it is necessary for him. And user B can do any
update on record 1 only after the updates done by A has been
committed or rollbacked. It is pretty clear - but this means, that A
is doining very long lasting transactions which can be simply
simulated by isql or any other DB tool, but it is almost impossible
to do with usual Delphi components. There is transaction with read-
commited when data are retrieved and another transaction when the
updated are applied to DB (it is under 1s). So - how it is possible
with Delphi (ibx) to make long lasting transaction? Are there some
common failures? As far as I know - then there read-commited can be
enabled for select commands, automatic rollback already occures for
any failure - there is simply not much chance to have long-lasting
transaction.

Well - and another question - is there some chances for user B to
detected, that some other user (e.g. A) is already doing some updates
on record 1 and so - user B can wait and do his updates later> is
there possibility to see, that record is locke by some other user...
I guess, that it is possible using the commercial IB, where tmp$...
tables are gather all the accounting information...

And - at last - is there some way to monitor, which is the user of
type A - who has started some long lasting transaction.

Vincent

--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

>
> vincent_kwinsey wrote:
> >
> > 1) the good news are that in principle some problems in

application

> > design cann't lead to errors like 'lock conversion denied', 'lock
> > denied'
>
> That's true.
>
> > 2) the not so good news items is, that on-disc structure has got
> > corrupted and hence these messaged. Am I right? Well, it may be

so,

> > but - if this is true - are these type of corruption bad and can

this

> > go to other records as well? Should be take immedate action and

try

> > to make gfix or backup-restore?
>
> It might be a corruption, but when I've seen those errors in the

past,

> they've been transient conditions caused by heavy contention - not
> errors in the stored data.
>
>
> Regards,
>
>
> Ann
> >
>