--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 09:47 AM 2/09/2006, you wrote:
> >Hi all,
> >
> >Yestardey I had a big problem with database corruption.
>
> What kind of database corruption? Are there any interesting

messages

> to indicate database corruption?
>
>
> >Objective:
> >
> >Fedora 3.0
> >Firebird 2.0 RC2
> >ForcedWrites = On
> >Page Buffers = 2000
> >Sweep Intervale = 20000
> >25-30 clients connected by ODBC driver
> >
> > >From time to time database stops (twice a week). Could not find

any

> >conection with actions of users and database fail. I look in LOG

file

> >and found 104, 32, 111 errors.
>
> They are network errors. 104 often means a user application

crashed,

> or a user simply switched off his machine. 32 is a broken pipe -
> faulty network hardware? 111 is connection refused - often

indicates

> that the server has been stopped.
>
> >After rebooting server everything is
> >Ok. Yesterday database faild about 12:00PM, the tehnician reboot

the

> >server (almost in a same way as power loss). After that database

was

> >corrupted. All data from 8:11AM was lost and it was a lot of data
> >(about 80 invoices).
> >
> >Where did I go wrong?
>
> Lost data is not a sign of a corrupt database unless you are

getting

> indicative messages from the server. It most likely means your
> application is not committing work in a timely manner. Four hours

is

> far too long to keep uncommitted work hanging around.
>
> Why are you rebooting the server? That's a fairly sure way to lose
> uncommitted work....
>
> >What can I do to stop this behaviour?
>
> Find out what is causing it. Tell us what messages the server is
> giving. Read the Bug Fixes sections of the release notes for RC3

and

> RC4 to check whether a bug in Firebird might be involved.
>
> Test a more recent beta. And don't run betas in production....
>
> ./heLen
>

Hi Helen,

I do commit after each entry so it must not be the problem. I have
significant database experience (8 years ... ASA9, Oracle) so the
answer is probably in your sentence "And don't run betas in
production...".
If you can help me with SuperServer Linux version of database, witch
one (Old Threading Library or NTPL) is appropriate for Fedora 3.0?
In this very moment I am using NTPL. Is this the source of my problem?

Regards Djole