The Database type exposes the following members.
Although closing a database will close any open cursors, it is recommended that applications explicitly close all their Cursor objects before closing the database. The reason why is that when the cursor is explicitly closed, the memory allocated for it is reclaimed; however, this will not happen if you close a database while cursors are still opened.
The same rule, for the same reasons, hold true for Transaction objects. Simply make sure you resolve all your transaction objects before closing your database handle.
Because key/data pairs are cached in memory, applications should make a point to always either close database handles or sync their data to disk (using Sync()()() before exiting, to ensure that any data cached in main memory are reflected in the underlying file system.
When called on a database that is the primary database for a secondary index, the primary database should be closed only after all secondary indices referencing it have been closed.
When multiple threads are using the object concurrently, only a single thread may call the Close method.
The object may not be accessed again after Close is called, regardless of its outcome.
Release the resources held by this object, and close the database if it's still open.(Inherited from BaseDatabase.)
Serves as a hash function for a particular type.(Inherited from Object.)
Gets the Type of the current instance.(Inherited from Object.)
Create a specialized join cursor for use in performing equality or natural joins on secondary indices.
If the database supports duplicates, add 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.
Flush any cached information to disk.(Inherited from BaseDatabase.)
When called on a database configured with secondary indices, Truncate will truncate the primary database and all secondary indices. A count of the records discarded from the primary database is returned.
Database upgrades are done in place and are destructive. For example, if pages need to be allocated and no disk space is available, the database may be left corrupted. Backups should be made before databases are upgraded. See Upgrading databases in the Programmer's Reference Guide for more information.
Verify does not perform any locking, even in Berkeley DB environments that are configured with a locking subsystem. As such, it should only be used on files that are not being modified by another thread of control.