Berkeley DB Reference Guide: Access Methods
Logically renumbering records (DB_RENUMBER)
Records stored in the Recno access method are accessed by logical record number. By default, these record numbers are not mutable. What that means is if you delete record number 5, record number 6 is not automatically renumbered to be record number 5 and 7 renumbered to be record number 6 and so on. For the same reason, new records cannot be inserted inbetween already existing records.
It is possible to make the logical record numbers mutable by specifying the DB_RENUMBER flag in the DB_INFO structure during the db_open call to open the database. This means that the record numbers may change change as records are added to and deleted from the database.
For example, the deletion of record number 4 causes records numbered 5 and greater to be renumbered downward by 1. If a cursor was positioned to record number 4 before the deletion, it will suddenly reference the new record number 4, if any such record exists, after the deletion. If a cursor was positioned after record number 4 before the deletion, it will be shifted downward 1 logical record, continuing to reference the same record as it did before.
Similarly, if a created record is not at the end of the database, all records following the new record will be automatically renumbered upward by 1. For example, the creation of a new record numbered 8 causes records numbered 8 and greater to be renumbered upward by 1. If a cursor was positioned to record number 8 or greater before the insertion, it will be shifted upward 1 logical record, continuing to reference the same record as it did before.
For these reasons, concurrent access to a Recno database with the DB_RENUMBER flag specified may be largely meaningless, although it is supported.
In the case of Recno databases where record numbers are not mutable, any attempt to retrieve deleted records will result in a special error return, DB_KEYEMPTY.
When using both mutable and immutable record numbers, creating new records will cause the creation of multiple records if the record number is more than one greater than the largest record currently in the database. For example, creating record number 28, when record 25 was previously the last record in the database, will create records 26 and 27 as well as 28.
First, last, next and previous cursor operations will automatically skip over implicitly created records. For example, if record number 5 is the only record the application has created, implicitly creating records 1 through 4, the DBcursor->c_get interface with the DB_FIRST flag will return record number 5, not record number 1. Attempts to explicitly retrieve records that were created in this manner will result in a special error return, DB_KEYEMPTY.
