Although many people use DAO from an executable file, you may want to create dynamic-link libraries (DLLs) for distribution so that others can use them in their applications. If you use a DLL, you must start DAO from inside the DLL. Various restrictions on DLLs prevent this from being done automatically while the DLL loads, and the dbDAO classes will not handle it for you. Instead, you must explicitly force the load.
For example, the following code works fine inside an executable, but the same code does not work as a DLL:
class CMyObj { public: CMyObj(); ~CMyObj(); private: CdbDBEngine m_cDBEng; }; CMyObj::CMyObj() { } CMyObj::~CMyObj() { delete m_cDBEng; } // Globally instantiated object - the cause of the DLL problem. CMyObj myObj; #ifdef MAKE_AS_DLL // Exported function that is called by some console application. // This case hangs. __declspec(dllexport) void hello() { } #else // When this is built as a console application, it works fine. void main() { return; } #endif // MAKE_AS_DLL
The line causing the problem is the declaration:
CMyObj myObj;
When the DLL is loaded and the class is instantiated, an attempt is made to start DAO. To work around this problem, you must create an entry point in your routine that explicitly creates DAO, and have your DLL users call that entry point. For example, you could do this as part of another initialization — for example, declaring the global variable as a pointer to CdbDBEngine and then constructing the class in your initialization function.