Library Version 11.2.5.3

DBcursor->put()
Prev | Chapter 3. The DBcursor Handle | Next

## DBcursor->put()

    #include <db.h>

    int
    DBcursor->put(DBC *DBcursor, DBT *key, DBT *data, u_int32_t flags);

The `DBcursor->put()` method stores key/data pairs into the database.

Unless otherwise specified, the `DBcursor->put()` method returns a non-zero error value on failure and 0 on success.

If `DBcursor->put()` fails for any reason, the state of the cursor will be unchanged. If `DBcursor->put()` succeeds and an item is inserted into the database, the cursor is always positioned to refer to the newly inserted item.

### Parameters

#### key

The key DBT operated on.

If creating a new record in a Heap database, the key DBT must be empty. The `put` method will return the new record's Record ID (RID) in the key DBT.

#### data

The data DBT operated on.

#### flags

The flags parameter must be set to one of the following values:

- `DB_AFTER`

  In the case of the Btree and Hash access methods, insert the data element as a duplicate element of the key to which the cursor refers. The new element appears immediately after the current cursor position. It is an error to specify DB_AFTER if the underlying Btree or Hash database is not configured for unsorted duplicate data items. The key parameter is ignored.

  In the case of the Recno access method, it is an error to specify DB_AFTER if the underlying Recno database was not created with the DB_RENUMBER flag. If the DB_RENUMBER flag was specified, a new key is created, all records after the inserted item are automatically renumbered, and the key of the new record is returned in the structure to which the key parameter refers. The initial value of the key parameter is ignored. See DB->open() for more information.

  The DB_AFTER flag may not be specified to the Queue access method.

  The `DBcursor->put()` method will return DB_NOTFOUND if the current cursor record has already been deleted and the underlying access method is Hash.

- `DB_BEFORE`

  In the case of the Btree and Hash access methods, insert the data element as a duplicate element of the key to which the cursor refers. The new element appears immediately before the current cursor position. It is an error to specify DB_AFTER if the underlying Btree or Hash database is not configured for unsorted duplicate data items. The key parameter is ignored.

  In the case of the Recno access method, it is an error to specify DB_BEFORE if the underlying Recno database was not created with the DB_RENUMBER flag. If the DB_RENUMBER flag was specified, a new key is created, the current record and all records after it are automatically renumbered, and the key of the new record is returned in the structure to which the key parameter refers. The initial value of the key parameter is ignored. See DB->open() for more information.

  The DB_BEFORE flag may not be specified to the Queue access method.

  The `DBcursor->put()` method will return DB_NOTFOUND if the current cursor record has already been deleted and the underlying access method is Hash.

- `DB_CURRENT`

  Overwrite the data of the key/data pair to which the cursor refers with the specified data item. The key parameter is ignored.

  The `DBcursor->put()` method will return DB_NOTFOUND if the current cursor record has already been deleted.

- `DB_KEYFIRST`

  Insert the specified key/data pair into the database.

  If the underlying database supports duplicate data items, and if the key already exists in the database and a duplicate sort function has been specified, the inserted data item is added in its sorted location. If the key already exists in the database and no duplicate sort function has been specified, the inserted data item is added as the first of the data items for that key.

- `DB_KEYLAST`

  Insert the specified key/data pair into the database.

  If the underlying database supports duplicate data items, and if the key already exists in the database and a duplicate sort function has been specified, the inserted data item is added in its sorted location. If the key already exists in the database, and no duplicate sort function has been specified, the inserted data item is added as the last of the data items for that key.

- `DB_NODUPDATA`

  In the case of the Btree and Hash access methods, insert the specified key/data pair into the database, unless a key/data pair comparing equally to it already exists in the database. If a matching key/data pair already exists in the database, DB_KEYEXIST is returned. The DB_NODUPDATA flag may only be specified if the underlying database has been configured to support sorted duplicate data items.

  The DB_NODUPDATA flag may not be specified to the Queue or Recno access methods.

### Errors

The `DBcursor->put()` method may fail and return one of the following non-zero errors:

#### DB_KEYEXIST

An attempt was made to insert a duplicate key into a database not configured for duplicate data.

#### DB_FOREIGN_CONFLICT

A foreign key constraint violation has occurred. This can be caused by one of two things:

1. An attempt was made to add a record to a constrained database, and the key used for that record does not exist in the foreign key database.

2. DB_FOREIGN_ABORT was declared for a foreign key database, and then subsequently a record was deleted from the foreign key database without first removing it from the constrained secondary database.

#### DB_HEAP_FULL

An attempt was made to add or update a record in a Heap database. However, the size of the database was constrained using the DB->set_heapsize() method, and that limit has been reached.

#### DB_LOCK_DEADLOCK

A transactional database environment operation was selected to resolve a deadlock.

#### DB_LOCK_NOTGRANTED

A Berkeley DB Concurrent Data Store database environment configured for lock timeouts was unable to grant a lock in the allowed time.

You attempted to open a database handle that is configured for no waiting exclusive locking, but the exclusive lock could not be immediately obtained. See DB->set_lk_exclusive() for more information.

#### DB_REP_HANDLE_DEAD

When a client synchronizes with the master, it is possible for committed transactions to be rolled back. This invalidates all the database and cursor handles opened in the replication environment. Once this occurs, an attempt to use such a handle will return `DB_REP_HANDLE_DEAD`. The application will need to discard the handle and open a new one in order to continue processing.

#### DB_REP_LOCKOUT

The operation was blocked by client/master synchronization.

#### EACCES

An attempt was made to modify a read-only database.

#### EINVAL

If the DB_AFTER, DB_BEFORE or DB_CURRENT flags were specified and the cursor has not been initialized; the DB_AFTER or DB_BEFORE flags were specified and a duplicate sort function has been specified; the DB_CURRENT flag was specified, a duplicate sort function has been specified, and the data item of the referenced key/data pair does not compare equally to the data parameter; the DB_AFTER or DB_BEFORE flags were specified, and the underlying access method is Queue; an attempt was made to add a record to a fixed-length database that was too large to fit; an attempt was made to add a record to a secondary index; or if an invalid flag value or parameter was specified.

#### EPERM

Write attempted on read-only cursor when the DB_INIT_CDB flag was specified to DB_ENV->open().

### Class

DBcursor

### See Also

Database Cursors and Related Methods

Prev | Up | Next
DBcursor->get_priority() | Home | DBcursor->set_priority()