Kevin.Stanton@...

asked for some information on these error messages...

> >
>
> DATA01 (Server) Tue Feb 15 08:37:12 2005
> Database: E:\IBDATA~1\LUMBER\LUMBER.GDB
> deadlock
> update conflicts with concurrent update
> operation was cancelled
> internal gds software consistency check (error during savepoint
> backout (290))

Nickolay (and others, no doubt) have fixed several obscure problems (aka
well-hidden bugs) in the savepoint code that can cause consistency check
errors. The fixes are in 1.5x but not 1.0x, if I recall correctly.

This series of messages suggests that the original error was an update
conflict. It probably occurred in a stored procedure that had no error
handling for update conflicts. Mixing what (little) I remember from the
changes to savepoint handling, the operation included multiple updates
to the same record in different, nested procedures.

>
> DATA01 (Server) Mon Feb 14 16:21:41 2005
> Database: E:\IBDATA~1\LUMBER\LUMBER_X.GDB
> Relation has 361 orphan backversions (207357 in use) in table
> CUSTOMERS (161)

Orphan back versions are benign results of server crashes. Firebird
keeps the database on disk consistent at all times - assuming you're
running with forced writes on. To do so, in the case of a garbage
collecting back version on a different page from the main version, it
first clears the pointer to the back version, writes that page, then
releases the back version and writes that page. If the server crashes
between the two operations, the back version continues to occupy space,
but isn't part of any particular record any more. Hence, orphaned.

>
>
> DATA01 (Client) Mon Feb 14 14:31:43 2005
> INET/inet_error: connect errno = 10061

Somebody tried to use a connection to a server after than server had
crashed.

> DATA01 (Server) Mon Feb 14 13:45:51 2005
> INET/inet_error: select in packet_receive errno = 10038

Somebody tried to use a connection to a server after than server had
crashed.


Regards,


Ann