Thanks Ann,

I will give that a try and see how it goes.

best regards

Dalton

Ann W. Harrison wrote:

>
> Hi Dalton,
> >
> > I am running with a standard configuration, and the time period between
> > such problems is averaging a month so a debug version on this database
> > system, would not be practical.
>
> Unfortunately, that's probably the only way to find the bug unless
> someone has a brilliant insight. I think it's possible to run a
> server compiled for debug and setup to produce a core file when
> it hits that error without having a debugger involved in the actual
> running. But we can return to that later.
>
> >
> > So, perhaps it is an issue with lock parametres. What setting would you
> > recommend for a database that has about 150 concurrent connections at
> > any one time with a average database size of 30 GB? The number of
> > tables, procedures and views is also on the order of about a thousand
> > objects or more......
>
> The size of the lock table is governed more by the number of buffers
> in use than any other single issue. Firebird holds one lock per user
> accessing a buffer, plus one lock per table referenced per user, plus
> locks on transactions, and a bunch of miscellaneous locks. However,
> the interesting ones are buffer locks since they tend to be numerous
> and volatile.
>
> If you have not changed the lock parameters from the installation,
> try changing these parameters:
>
> #
> #LockMemSize = 262144
>
> Uncomment it and set it to 1Mb (1048576)
>
> #LockHashSlots = 101
>
> Uncomment it and set it to 401
>
> Changing the parameters won't find or fix the bug - the change
> just hides the bug until systems get bigger and faster and we
> trip over it again. And if the bug is not a boundary condition
> on lock table size, changing the parameters won't help at all.
> But it shouldn't hurt.
>
> Best,
>
> Ann
>
>