Db::put |
#include <db_cxx.h>int Db::put(DbTxn *txnid, Dbt *key, Dbt *data, u_int32_t flags);
The Db::put method stores key/data pairs in the database. The default behavior of the Db::put function is to enter the new key/data pair, replacing any previously existing key if duplicates are disallowed, or adding a duplicate data item if duplicates are allowed. If the database supports duplicates, the Db::put method adds the new data value at the end of the duplicate set. If the database supports sorted duplicates, the new data value is inserted at the correct sorted location.
If the operation is to be transaction-protected, the txnid parameter is a transaction handle returned from DbEnv::txn_begin; otherwise, NULL.
The flags value must be set to 0 or one of the following values:
There is a minor behavioral difference between the Recno and Queue access methods for the DB_APPEND flag. If a transaction enclosing a Db::put operation with the DB_APPEND flag aborts, the record number may be decremented (and later reallocated by a subsequent DB_APPEND operation) by the Recno access method, but will not be decremented or reallocated by the Queue access method.
The DB_NODUPDATA flag may not be specified to the Queue or Recno access methods.
Otherwise, the Db::put method either returns a non-zero error value or throws an exception that encapsulates a non-zero error value on failure, and returns 0 on success.
The Db::put method may fail and throw an exception or return a non-zero error for the following conditions:
A record number of 0 was specified.
An attempt was made to add a record to a fixed-length database that was too large to fit.
An attempt was made to do a partial put.
An attempt was made to add a record to a secondary index.
The Db::put method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. If a catastrophic error has occurred, the Db::put method may fail and either return DB_RUNRECOVERY or throw an exception encapsulating DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail in the same way.