Lazarus. Firebird and Zeos Tips and Tricks
Multiple access to the Firebird database during development:
Anyone who has developed Lazarus database applications has a plague. When editing the program you often need the connection to the database. If one forgets then (with Zeos the check mark with ZConnection-> Connected) the connection to Firebird before compiling and testing of the program / program part separate a message appears that the data base from another access is used and the program can not be executed , The same problem occurs when you want to access the database file with a database tool.
There is a trick, with which one can prevent this with the installed, as well as with the embedded version of Firebird. However, this setting should only work with test data, never with live data.
The procedure is the same with the installed Firebird application 3 or 4 as well as with the embedded version, with the difference that with the installed version the used text editor with administrator rights must be started.
Start an editor and load the file in the Firebird program directory and load the file "firebird.conf" into the editor. At the end of this file, type the following:
ServerMode = SuperClassic
SharedCache = true
SharedDatabase = true
Then save the file "firebird.conf". That was it. From now on you do not need to disconnect from the database to start your newly compiled program. As I said, this also works for an installed server. However, what only works with the embedded version of Firebird is calling another program, such as the database tool Turbobird. However, if you want to overwrite a database, you must close the access to the database file for all variants.
That says Firebird to SuperClassic:
SuperClassic / ThreadedShared - databases are opened by single server process, but it does not prevent them in other processes (embedded access),
Each attachment has its own DB pages cache.
SuperClassic / ThreadedShared - Databases are opened by a single server process, but do not prevent them from opening in other processes (embedded access). Each access has its own DB page cache.
When delivering a program with the embedded version, this may be necessary so that a table can be read several times. I have not tested that yet.