Berkeley DB Reference Guide:
Building Berkeley DB for Windows systems

PrevRefNext

Frequently Asked Questions

  1. My Win* C/C++ application crashes in the Berkeley DB library when Berkeley DB calls fprintf (or some other standard C library function).

    You should be using the "Debug Multithreaded DLL" compiler option in your application when you link with the build_win32/Debug/libdb30d.lib library (this .lib file is actually a stub for libdb30d.DLL). To check this setting in Visual C++, choose the "Project/Settings" menu item, and under the tab marked "C/C++", select "Code Generation" and see the box marked "Use runtime library". This should be set to "Debug Multithreaded DLL". If your application is linked against the static library, build_win32/Debug/libdb30sd.lib, then you will want to set "Use runtime library" to "Debug Multithreaded".

    Setting this option incorrectly can cause multiple versions of the standard libraries to be linked into your application (one on behalf of your application, and one on behalf of the Berkeley DB library). That violates assumptions made by these libraries, and traps can result.

  2. Why are the build options for DB_DLL marked as "Use MFC in a Shared DLL"? Does Berkeley DB use MFC?

    Berkeley DB does not use MFC at all. It does however, call malloc and free and other facilities provided by the Microsoft C runtime library. We've found in our work that many applications and libraries are built assuming MFC, and specifying this for Berkeley DB solves various interoperation issues, and guarantees that the right runtime libraries are selected. Note that since we do not use MFC facilities, the MFC library DLL is not marked as a dependency for libdb.dll, but the appropriate Microsoft C runtime is.

  3. Multiple processes on Windows/95 fail to see each other's database updates.

    On Windows/95, files that are opened by multiple processes do not share data correctly. To cause Berkeley DB to use the paging file to share memory among processes, use the DB_SYSTEM_MEM flag to the DBENV->open function. Obviously, you do not need to do this if only a single process will be accessing database files.


PrevRefNext

Copyright Sleepycat Software