Set the underlying source file for the Recno access method. The purpose
of the re_source value is to provide fast access and modification
to databases that are normally stored as flat text files.
If the re_source field is set, it specifies an underlying flat
text database file that is read to initialize a transient record number
index. In the case of variable length records, the records are separated
as specified by DB->set_re_delim. For example, standard UNIX
byte stream files can be interpreted as a sequence of variable length
records separated by <newline> characters.
In addition, when cached data would normally be written back to the
underlying database file (e.g., the DB->close or DB->sync
methods are called), the in-memory copy of the database will be written
back to the re_source file.
By default, the backing source file is read lazily, i.e., records are not
read from the file until they are requested by the application.
If multiple processes (not threads) are accessing a Recno database
concurrently and either inserting or deleting records, the backing source
file must be read in its entirety before more than a single process
accesses the database, and only that process should specify the backing
source file as part of the DB->open call. See the DB_SNAPSHOT
flag for more information.
Reading and writing the backing source file specified by re_source
cannot be transactionally protected because it involves filesystem
operations that are not part of the Db transaction methodology.
For this reason, if a temporary database is used to hold the records,
i.e., a NULL was specified as the file argument to DB->open,
it is possible to lose the contents of the re_source file, e.g.,
if the system crashes at the right instant.
If a file is used to hold the database, i.e., a file name was specified
as the file argument to DB->open, normal database
recovery on that file can be used to prevent information loss,
although it is still possible that the contents of re_source
will be lost if the system crashes.
The re_source file must already exist (but may be zero-length) when
DB->open is called.
It is not an error to specify a read-only re_source file when
creating a database, nor is it an error to modify the resulting database.
However, any attempt to write the changes to the backing source file using
either the DB->sync or DB->close functions will fail, of course.
Specify the DB_NOSYNC flag to the DB->close function to stop it
from attempting to write the changes to the backing file, instead, they
will be silently discarded.
For all of the above reasons, the re_source field is generally
used to specify databases that are read-only for DB applications,
and that are either generated on the fly by software tools, or modified
using a different mechanism, e.g., a text editor.
The DB->set_re_source interface may only be used to configure Berkeley DB before
the DB->open interface is called.
The DB->set_re_source function returns a non-zero error value on failure and 0 on success.