Next: Database consistency, Previous: Export and Import, Up: The GNU database manager [Contents][Index]
The global variable gdbm_errno (see gdbm_errno)
keeps the error code of the most recent error encountered by GDBM
functions.
To convert this code to human-readable string, use the following function:
Converts errno (an integer value) into a human-readable descriptive text. Returns a pointer to a static string. The caller must not free the returned pointer or alter the string it points to.
Detailed information about the most recent error that occurred while
operating on a GDBM file is stored in the GDBM_FILE object
itself. To retrieve it, the following functions are provided:
Returns the code of the most recent error encountered when operating on dbf.
When gdbm_last_errno called immediately after the failed
function, its return equals the value of the gdbm_errno
variable. However, gdbm_errno can be changed if any
GDBM functions (operating on another databases) were called
afterwards, and gdbm_last_errno will always return the code of
the last error that occurred while working with that database.
Returns the value of the system errno variable associated with
the most recent error.
Notice, that not all GDBM errors have an associated system error
code. The following are the ones that have:
For other errors, gdbm_last_syserr will return 0.
Returns 1, if the system errno value should be inspected
to get more info on the error described by GDBM error code
err.
To get a human-readable description of the recent error for a
particular database file, use the gdbm_db_strerror function:
Returns textual description of the most recent error encountered when
operating on the database dbf. The resulting string is often
more informative than what would be returned by
gdbm_strerror(gdbm_last_errno(dbf)). In particular, if
there is a system error associated with the recent failure, it will be
described as well.
Clears the error state for the database dbf. Normally, this
function is called upon the entry to any GDBM function.
Certain errors (such as write error when saving stored key) can leave
database file in inconsistent state (see Database consistency).
When such a critical error occurs, the database file is marked as
needing recovery. Subsequent calls to any GDBM functions for that
database file (except gdbm_recover), will return immediately
with GDBM error code GDBM_NEED_RECOVERY. Additionally, the
following function can be used to check the state of the database file:
Returns 1 if the database file dbf is in inconsistent
state and needs recovery.
To restore structural consistency of the database, use the
gdbm_recover function (see Recovering structural consistency).
Crash tolerance provides a better way of recovery, because it restores both structural and logical consistency. See Crash Tolerance, for a detailed discussion,
Next: Database consistency, Previous: Export and Import, Up: The GNU database manager [Contents][Index]