Berkeley DB Reference Guide: Release 2.0: converting applications

Berkeley DB Reference Guide:
Upgrading Berkeley DB Applications

Release 2.0: converting applications

Mapping the Berkeley DB 1.85 functionality into Berkeley DB version 2 is almost always simple. The manual page DB->open replaces the Berkeley DB 1.85 manual pages dbopen(3), btree(3), hash(3) and recno(3). You should be able to convert each 1.85 function call into a Berkeley DB version 2 function call using just the DB->open documentation.

Some guidelines and things to watch out for:

Most access method functions have exactly the same semantics as in Berkeley DB 1.85, although the arguments to the functions have changed in some cases. To get your code to compile, the most common change is to add the transaction ID as an argument (NULL, since Berkeley DB 1.85 did not support transactions.)
You must always initialize DBT structures to zero before using them with any Berkeley DB version 2 function. (They do not normally have to be reinitialized each time, only when they are first allocated. Do this by declaring the DBT structure external or static, or by calling the C library routine bzero(3) or memset(3).)
The error returns are completely different in the two versions. In Berkeley DB 1.85, < 0 meant an error, and > 0 meant a minor Berkeley DB exception. In Berkeley DB 2.0, > 0 means an error (the Berkeley DB version 2 functions return errno on error) and < 0 means a Berkeley DB exception. See Error Returns to Applications for more information.
The Berkeley DB 1.85 DB->seq function has been replaced by cursors in Berkeley DB version 2. The semantics are approximately the same, but cursors require the creation of an extra object (the DBC object), which is then used to access the database.
Specifically, the partial key match and range search functionality of the R_CURSOR flag in DB->seq has been replaced by the DB_SET_RANGE flag in DBcursor->get.
In version 2 of the Berkeley DB library, additions or deletions into Recno (fixed and variable-length record) databases no longer automatically logically renumber all records after the add/delete point, by default. The default behavior is that deleting records does not cause subsequent records to be renumbered, and it is an error to attempt to add new records between records already in the database. Applications wanting the historic Recno access method semantics should call the DB->set_flags method with the DB_RENUMBER flag.
Opening a database in Berkeley DB version 2 is a much heavier-weight operation than it was in Berkeley DB 1.85. Therefore, if your historic applications were written to open a database, perform a single operation, and close the database, you may observe performance degradation. In most cases, this is due to the expense of creating the environment upon each open. While we encourage restructuring your application to avoid repeated opens and closes, you can probably recover most of the lost performance by simply using a persistent environment across invocations.

While simply converting Berkeley DB 1.85 function calls to Berkeley DB version 2 function calls will work, we recommend that you eventually reconsider your application's interface to the Berkeley DB database library in light of the additional functionality supplied by Berkeley DB version 2, as it is likely to result in enhanced application performance.