DBM_CLEARERR(3)            POSIX Programmer's Manual           DBM_CLEARERR(3)



PPRROOLLOOGG
       This manual page is part of the POSIX Programmer's Manual.  The OS
       implementation of this interface may differ (consult the corresponding
       OS manual page for details of OS behavior), or the interface may not be
       implemented on OS.

NNAAMMEE
       dbm_clearerr, dbm_close, dbm_delete, dbm_error, dbm_fetch,
       dbm_firstkey, dbm_nextkey, dbm_open, dbm_store -- database functions

SSYYNNOOPPSSIISS
       #include <ndbm.h>

       int dbm_clearerr(DBM *_d_b);
       void dbm_close(DBM *_d_b);
       int dbm_delete(DBM *_d_b, datum _k_e_y);
       int dbm_error(DBM *_d_b);
       datum dbm_fetch(DBM *_d_b, datum _k_e_y);
       datum dbm_firstkey(DBM *_d_b);
       datum dbm_nextkey(DBM *_d_b);
       DBM *dbm_open(const char *_f_i_l_e, int _o_p_e_n___f_l_a_g_s, mode_t _f_i_l_e___m_o_d_e);
       int dbm_store(DBM *_d_b, datum _k_e_y, datum _c_o_n_t_e_n_t, int _s_t_o_r_e___m_o_d_e);

DDEESSCCRRIIPPTTIIOONN
       These functions create, access, and modify a database.

       A ddaattuumm consists of at least two members, _d_p_t_r and _d_s_i_z_e.  The _d_p_t_r
       member points to an object that is _d_s_i_z_e bytes in length. Arbitrary
       binary data, as well as character strings, may be stored in the object
       pointed to by _d_p_t_r.

       A database shall be stored in one or two files. When one file is used,
       the name of the database file shall be formed by appending the suffix
       ..ddbb to the _f_i_l_e argument given to _d_b_m___o_p_e_n().  When two files are used,
       the names of the database files shall be formed by appending the
       suffixes ..ddiirr and ..ppaagg respectively to the _f_i_l_e argument.

       The _d_b_m___o_p_e_n() function shall open a database. The _f_i_l_e argument to the
       function is the pathname of the database. The _o_p_e_n___f_l_a_g_s argument has
       the same meaning as the _f_l_a_g_s argument of _o_p_e_n() except that a database
       opened for write-only access opens the files for read and write access
       and the behavior of the O_APPEND flag is unspecified. The _f_i_l_e___m_o_d_e
       argument has the same meaning as the third argument of _o_p_e_n().

       The _d_b_m___o_p_e_n() function need not accept pathnames longer than
       {PATH_MAX}-4 bytes (including the terminating null), or pathnames with
       a last component longer than {NAME_MAX}-4 bytes (excluding the
       terminating null).

       The _d_b_m___c_l_o_s_e() function shall close a database. The application shall
       ensure that argument _d_b is a pointer to a ddbbmm structure that has been
       returned from a call to _d_b_m___o_p_e_n().

       These database functions shall support an internal block size large
       enough to support key/content pairs of at least 1023 bytes.

       The _d_b_m___f_e_t_c_h() function shall read a record from a database. The
       argument _d_b is a pointer to a database structure that has been returned
       from a call to _d_b_m___o_p_e_n().  The argument _k_e_y is a ddaattuumm that has been
       initialized by the application to the value of the key that matches the
       key of the record the program is fetching.

       The _d_b_m___s_t_o_r_e() function shall write a record to a database. The
       argument _d_b is a pointer to a database structure that has been returned
       from a call to _d_b_m___o_p_e_n().  The argument _k_e_y is a ddaattuumm that has been
       initialized by the application to the value of the key that identifies
       (for subsequent reading, writing, or deleting) the record the
       application is writing. The argument _c_o_n_t_e_n_t is a ddaattuumm that has been
       initialized by the application to the value of the record the program
       is writing. The argument _s_t_o_r_e___m_o_d_e controls whether _d_b_m___s_t_o_r_e()
       replaces any pre-existing record that has the same key that is
       specified by the _k_e_y argument. The application shall set _s_t_o_r_e___m_o_d_e to
       either DBM_INSERT or DBM_REPLACE. If the database contains a record
       that matches the _k_e_y argument and _s_t_o_r_e___m_o_d_e is DBM_REPLACE, the
       existing record shall be replaced with the new record. If the database
       contains a record that matches the _k_e_y argument and _s_t_o_r_e___m_o_d_e is
       DBM_INSERT, the existing record shall be left unchanged and the new
       record ignored. If the database does not contain a record that matches
       the _k_e_y argument and _s_t_o_r_e___m_o_d_e is either DBM_INSERT or DBM_REPLACE,
       the new record shall be inserted in the database.

       If the sum of a key/content pair exceeds the internal block size, the
       result is unspecified. Moreover, the application shall ensure that all
       key/content pairs that hash together fit on a single block. The
       _d_b_m___s_t_o_r_e() function shall return an error in the event that a disk
       block fills with inseparable data.

       The _d_b_m___d_e_l_e_t_e() function shall delete a record and its key from the
       database. The argument _d_b is a pointer to a database structure that has
       been returned from a call to _d_b_m___o_p_e_n().  The argument _k_e_y is a ddaattuumm
       that has been initialized by the application to the value of the key
       that identifies the record the program is deleting.

       The _d_b_m___f_i_r_s_t_k_e_y() function shall return the first key in the database.
       The argument _d_b is a pointer to a database structure that has been
       returned from a call to _d_b_m___o_p_e_n().

       The _d_b_m___n_e_x_t_k_e_y() function shall return the next key in the database.
       The argument _d_b is a pointer to a database structure that has been
       returned from a call to _d_b_m___o_p_e_n().  The application shall ensure that
       the _d_b_m___f_i_r_s_t_k_e_y() function is called before calling _d_b_m___n_e_x_t_k_e_y().
       Subsequent calls to _d_b_m___n_e_x_t_k_e_y() return the next key until all of the
       keys in the database have been returned.

       The _d_b_m___e_r_r_o_r() function shall return the error condition of the
       database. The argument _d_b is a pointer to a database structure that has
       been returned from a call to _d_b_m___o_p_e_n().

       The _d_b_m___c_l_e_a_r_e_r_r() function shall clear the error condition of the
       database. The argument _d_b is a pointer to a database structure that has
       been returned from a call to _d_b_m___o_p_e_n().

       The _d_p_t_r pointers returned by these functions may point into static
       storage that may be changed by subsequent calls.

       These functions need not be thread-safe.

RREETTUURRNN VVAALLUUEE
       The _d_b_m___s_t_o_r_e() and _d_b_m___d_e_l_e_t_e() functions shall return 0 when they
       succeed and a negative value when they fail.

       The _d_b_m___s_t_o_r_e() function shall return 1 if it is called with a _f_l_a_g_s
       value of DBM_INSERT and the function finds an existing record with the
       same key.

       The _d_b_m___e_r_r_o_r() function shall return 0 if the error condition is not
       set and return a non-zero value if the error condition is set.

       The return value of _d_b_m___c_l_e_a_r_e_r_r() is unspecified.

       The _d_b_m___f_i_r_s_t_k_e_y() and _d_b_m___n_e_x_t_k_e_y() functions shall return a key
       ddaattuumm.  When the end of the database is reached, the _d_p_t_r member of the
       key is a null pointer. If an error is detected, the _d_p_t_r member of the
       key shall be a null pointer and the error condition of the database
       shall be set.

       The _d_b_m___f_e_t_c_h() function shall return a content ddaattuumm.  If no record in
       the database matches the key or if an error condition has been detected
       in the database, the _d_p_t_r member of the content shall be a null
       pointer.

       The _d_b_m___o_p_e_n() function shall return a pointer to a database structure.
       If an error is detected during the operation, _d_b_m___o_p_e_n() shall return a
       (DDBBMM **)0.

EERRRROORRSS
       No errors are defined.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
       None.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       The following code can be used to traverse the database:


           for(key = dbm_firstkey(db); key.dptr != NULL; key = dbm_nextkey(db))

       The _d_b_m__* functions provided in this library should not be confused in
       any way with those of a general-purpose database management system.
       These functions do not provide for multiple search keys per entry, they
       do not protect against multi-user access (in other words they do not
       lock records or files), and they do not provide the many other useful
       database functions that are found in more robust database management
       systems. Creating and updating databases by use of these functions is
       relatively slow because of data copies that occur upon hash collisions.
       These functions are useful for applications requiring fast lookup of
       relatively static information that is to be indexed by a single key.

       Note that a strictly conforming application is extremely limited by
       these functions: since there is no way to determine that the keys in
       use do not all hash to the same value (although that would be rare), a
       strictly conforming application cannot be guaranteed that it can store
       more than one block's worth of data in the database. As long as a key
       collision does not occur, additional data may be stored, but because
       there is no way to determine whether an error is due to a key collision
       or some other error condition (_d_b_m___e_r_r_o_r() being effectively a
       Boolean), once an error is detected, the application is effectively
       limited to guessing what the error might be if it wishes to continue
       using these functions.

       The _d_b_m___d_e_l_e_t_e() function need not physically reclaim file space,
       although it does make it available for reuse by the database.

       After calling _d_b_m___s_t_o_r_e() or _d_b_m___d_e_l_e_t_e() during a pass through the
       keys by _d_b_m___f_i_r_s_t_k_e_y() and _d_b_m___n_e_x_t_k_e_y(), the application should reset
       the database by calling _d_b_m___f_i_r_s_t_k_e_y() before again calling
       _d_b_m___n_e_x_t_k_e_y().  The contents of these files are unspecified and may not
       be portable.

       Applications should take care that database pathname arguments
       specified to _d_b_m___o_p_e_n() are not prefixes of unrelated files. This might
       be done, for example, by placing databases in a separate directory.

       Since some implementations use three characters for a suffix and others
       use four characters for a suffix, applications should ensure that the
       maximum portable pathname length passed to _d_b_m___o_p_e_n() is no greater
       than {PATH_MAX}-4 bytes, with the last component of the pathname no
       greater than {NAME_MAX}-4 bytes.

RRAATTIIOONNAALLEE
       Previously the standard required the database to be stored in two
       files, one file being a directory containing a bitmap of keys and
       having ..ddiirr as its suffix. The second file containing all data and
       having ..ppaagg as its suffix. This has been changed not to specify the use
       of the files and to allow newer implementations of the Berkeley DB
       interface using a single file that have evolved while remaining
       compatible with the application programming interface. The standard
       developers considered removing the specific suffixes altogether but
       decided to retain them so as not to pollute the application file name
       space more than necessary and to allow for portable backups of the
       database.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _o_p_e_n()

       The Base Definitions volume of POSIX.1-2017, <<nnddbbmm..hh>>

CCOOPPYYRRIIGGHHTT
       Portions of this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1-2017, Standard for Information Technology --
       Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the
       Institute of Electrical and Electronics Engineers, Inc and The Open
       Group.  In the event of any discrepancy between this version and the
       original IEEE and The Open Group Standard, the original IEEE and The
       Open Group Standard is the referee document. The original Standard can
       be obtained online at http://www.opengroup.org/unix/online.html .

       Any typographical or formatting errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files to man page format. To report such errors, see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2017                      DBM_CLEARERR(3)
