At 07:27 AM 20/10/2006, Stan wrote:

>off topic:
>------------
>I like it how on this newsgroup the first assumption is always user
>error :) I mean no disrespect to the very experienced and helpful
>proffesionals that take their time to patrol this group.

And I like it (NOT) how some people think that it's wrong to approach
a troubleshoot by eliminating identifiable extraneous causes first.

You wrote:

>-------------
>
>on topic:
>--------------
>I have had a similar issue.
>
>I filed a reproducible test-case into the Firebird tracker:
>http://tracker.firebirdsql.org/browse/CORE-5
>
>Here is how I got around my issue:
>
>1. Make sure that you are not updating the same record more than once
>in a single transaction.
>
>2. Make sure that you dont have triggers and/or stored procedures
>that call one another, creating a "deep" stack of procedure calls.
>These "deep" call-stacks mixed with a lot of concurrent load, is
>how my test-case duplicates this issue.
>
>
>let us know if these suggestions fixed your problem.

I hope that attending to these design details, if they are part of
the picture, will help to solve the problem. However, to get back ON
topic, your report does not include this in its list of symptoms
(requoting from Gerrit's original posting):

>After that all accesses to the database fail, because the database

file 'is locked by another process'.

This says that the engine can't accept requests because another
process is preventing it from accessing the database file. This *is*
an extraneous condition, that is giving rise to the internal
inconsistency. It's also NOT NECESSARILY a "user error", although it
does rather look like an environmental one at this point...

./heLen