carusoaldo wrote:

> Thanks for your answer, but I noticed that in the previous server (
> Fedora Core 2 + FirebirdSS-1.5.2.4731-0 ) those attributes are equal
> than those in the current server ( debian etch +
> firebird2-super-server 1.5.3.4870-12 ). And the bug never appeared in
> the previous server with the same database.
>

None the less, the only way you get that error is to have the lock
manager try to allocate a new block and fail because the lock table
is full. Maybe you changed the number of buffers in the cache?
Maybe you've got a couple more users? Maybe the overall timing of
the application is different, giving more concurrent page accesses?

Whatever the cause, the solution is to fix the lock table configuration
parameters.


Here's more detail from a question last September when I was less
terse.

The size of the lock table can be increased by changing
this parameter in the firebird.conf file:

# Bytes of shared memory allocated for lock manager.
# In Classic mode, the size given is used for the initial
# allocation. The table expands dynamically up to the
# limit of memory. In SuperServer, the initial size is
# also the final size.
# Default is 96K on Linux and Solaris, 256K on Windows.
#
# Type: integer
#
#LockMemSize = 262144

remove the leading '#' in the last line and double
or quadruple the value. The number is in bytes, so
you're not going to use much memory on a modern machine.

You should also increase the width of the lock hash table,
in the entry below. Pick a prime number between 211 and
503 - lower if you double the table, higher if you quadruple
it.

#
# Tune lock hash list; more hash slots mean shorter hash chains. Only
# necessary under very high load. Prime number values are recommended.
#
# Type: integer
#
#LockHashSlots = 101


Regards,


Ann