At 07:07 AM 25-06-02 +0000, you wrote:

>Hi
>
>I have earlier on posted several messages regarding the sweep
>function in FireBird version 1.0 (Build 794).
>
>Everytime everybody told, that there is no problem.
>
>But I can (on 2 different servers in 2 different networks, and on 2
>different machines standing "alone") make this error occur CONSTANTLY.
>
>The ONLY way I can solve this problem is by disabling the sweep and
>then manually do a sweep.
>
>When my error occurs my DB is so damaged that ONLY a Backup - Restore
>rutine will help.

This is too vague. A DB that is physically damaged can't be backed up so,
whatever is going on, something in your overall environment is breaking
something (data structures? indexes? orphaning transactions? I haven't
seen any hard information...)

>In my specific case it happens like this:
>
>1.
>When a new user tries to CONNECT while the DB is being sweepted then
>the DB gets corrupted.
>
>2.
>When an already connected user disconnects the same happens.

It's hard to see how sweeping is implicated in corruption that is
coincidental with users connecting and disconnecting. Sweeping removes
back versions of rows that have been made obsolete by either committed or
rolled back transactions. It operates on the artifacts of operations that
are already complete. It has nothing to do with users or connections at
all. It's also hard to see how you were able to ascertain that sweeping
was occurring when a user connected or disconnected.

>Here efter no one can access the DB until a Backup - Restore has been
>issued.

If backup and restore fixes your problems, then it's likely there is data
structure damage occurring from causes external to the database: the
commonest of these is a disk with corrupted blocks. Have you performed any
thorough disk surface scans during your investigations? Note that if you
filecopy a damaged database to another disk, you will merely copy any data
flaws engendered by damage on the original disk...

Data structure damage can also occur when a filesystem copying program is
run whilst transactions are active in the database. Compression utilities,
system backup utilities, even a naive system admin performing copy/paste...

You can - and probably will - break data structures if you have application
programs that perform DML on system tables. This includes some of the more
naive third-party utility tools, not just your own application code.

>Now some questions:
>
>1.
>Why do people tell me, that the sweep bug has been fixed, where as
>far as I'm concerned it has NOT !

What sweep bug are you referring to?

>2.
>In which NG can I discuss BUGS in firebird ?

Firebird-devel@... - List-Subscribe:
<https://lists.sourceforge.net/lists/listinfo/firebird-devel>

I have to observe that your postings on and around this topic have
been confused, confusing, contradictory and based on illogical assumptions
(like connecting during a sweep corrupts databases...)

If you think you are observing a bug, make things simple by reporting the
versions of all servers and clients concerned, describing the conditions
exactly, including the server and client platforms, the network
protocol, tasks that the server was performing when corruption was
supposed to have occurred (both the database server and other services on
the server machine); and pasting any relevant snippets from interbase.log
files.

I know how frustrating it can be when things are going wrong - but things
tend to go more and more wrong when you focus on the unlikely while
overlooking the obvious. Problem definition should not be a process of
squeezing drops of blood from a rock.

heLen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________