Hi,
We've got a system which does different things depending on whether
"forced writes" is switched on or not (and, possibly, on /when/ it's
switched on or off).
It seems to me that this is wrong - turning forced writes on or off
should only affect performance, it shouldn't make an application follow
different paths through the code?
So my first assumption is that in fact forced write state is not
actually causing Firebird to behave in different ways, and that we've got
(a) some of our application code that is timing dependent, or
(b) something else wrong, and the repeatable changes in behaviour when
switching forced writes on and off are just an amazing coincidence.
But just to eliminate the most unlikely explanation first, and get that
out of the way, please can someone confirm to me very strenuously indeed
that there is no possibility that
(c) switching forced writes on or off changes the logical behaviour of a
Firebird application
whether through changing the outcome of multiple concurrent transactions
or otherwise?
This is Firebird 2.5 running on 64 bit Linux. The application consists
of a bunch of processes written in C/C++ accessing the database, partly
direct queries and partly stored procedure calls, as well as user
interface accesses via PHP. (Oh, and possibly some Python processes and
other stuff, but it's the interaction between a couple of the C/C++
processes that is currently confusing us.)
--
Tim Ward
