At 12:06 PM 12/03/2005 +0000, you wrote:

>Helen,
>
>there is one big wrong assumption in your post: there was NOT power
>outage in my case. Neither any error, returned by the application or
>the DB engine. Just running the application second time I got this
>message (after writing many, many records to the DB). Then checked
>with isql - the same. The PC never went down, rebooted, crashed or
>anything else like this. The DB connection was properly closed. I
>said 'supposed' only to discuss such a case - I need to provide a
>reliable application, so I explore all cases.

OK, so your provocative argument that you weren't prepared to have data
integrity assured at the cost of some assumptive performance benefit was a
red herring?

>About open-source... I am involved in 3 open source projects, and,
>no, this is not free beer. I guess (wrong again?) that open source
>software is driven by the will of people to share and provide others
>with the fruits of their experience and knowledge.

Yep, that's a good summary of the open source I know and live with. People
have free and open access to the source code so they can work out for
themselves what's going on and may even be inspired to contribute something.

>But there is something totally wrong behind the concept "get the software for
>free, but you must pay for support".

Uh-huh. So, you're somehow deprived of a god-given right if you stuff
something up and you have to --gasp-- PAY someone to analyse and fix
it? Never mind what it costs other people, it's totally wrong if you can't
get everything for free, from cradle to grave? Hmm, that's an open source
model I don't relate to. I run Red Hat Linux on one server and Mandrake on
another. Both are open source but there's no free support. I don't mind
that. It's a privilege for me just to have that wonderful software for
nothing. If I get stuck, I Google. If Google doesn't yield what I need, I
buy a book.

>Of course, there is sometime
>need for such support, but even for a DB maintenance?... DB
>maintenance should be part of a DB software. From my point of view,
>of course.

There's a difference between DB maintenance (for which you only need to
learn the skills) and fixing up a DB that you've managed to corrupt, by
some obscure means. The database engine protects databases from
corruption; but it can't always protect them from humans. Be assured that
fixing corrupt databases is not a "maintenance task" in Firebird, whatever
your experiences might be with other systems.

>About Windows... Hey, there are CUSTOMERS and bosses out there - they
>decide what to run the software on. If FB doesn't work well on
>Windows... well, don't advertise it does so.

It does work well on Windows - but know the animal, because Windows has
fangs gnashing for the careless DBA - such as not writing the OS cache to
disk; on XP, locking and image-copying files that have a ".gdb" extension
immediately the first user tries to log in; running disk backup utilities
that lock blocks of disk that the engine absolutely must keep writable; et al.

>I was asking for help and advice. This is what forums and news groups
>are for - support and collaboration. Between colleagues and
>professionals.

Tell me about it. :-|

A very effective way to make these forums work for you is to provide a
precise problem description from the start, rather than launch into a flame
attack based on wrong assumptions and conjecture. At
http://firebird.sourceforge.net/index.php?op=lists you will find a link to
a fairly famous article by ESR, on the subject of asking smart
questions. It's also about what forums and newsgroups are for - and
about. Worth taking on board.

In your case, *something* nasty is lurking in your setup, since the
Firebird engine doesn't corrupt databases: the server doesn't and the API
library doesn't. It's designed *not* to. There are currently one or two
"gotchas" that can lead to logical corruption - such as forgetting to
commit a metadata change before attempting to apply data to the changed
object - so a better than "passing knowledge" of how the engine does things
is a worthy objective to be shared by colleagues and
professionals. However, if you got a corrupt database page inventory just
from running two instances of your application, then something's lurking
there that didn't oughtta be.

Windows does, occasionally, given the favourable opportunity, know ways to
break Firebird databases. Trying to use a Windows share, mapping or
logical location as a server location does it. Writing to the same
physical database as though it were two different path locations certainly
does it (not possible with Superserver, but faintly possible with
Classic). Different hostnames: fine. Different pathnames: fatal. To
eliminate the human factor, you should make an alias in aliases.conf, that
is the exact PHYSICAL absolute path to the database file and then *always*
use the alias.

Faulty hardware (hard drives, network cards) can do it. Power surges and
shorts can toast pieces of disk. Spilling liquids - even free beer - into
a running server can do it. Sticking a screwdriver inside a running server
can do it.

>Anyway, may be this thread will be useful for me from another perspective.

With perseverance, eventually, we'll discover what could have caused your
DB corruption. It won't fix your database; but it will help you to
understand why the warnings are there in the documentation.

>BTW: Is Force Writes enabled by default? I never changed this option.

If you created the database using InterBase, then NO, it's off by
default. If you created it using a release version of Firebird, then YES,
it's on by default. You can check it - presumably on your restored backup
- by running gstat -h. You'll find the Forced Writes status in the
Attributes section near the end.

./hb