Although many people use DAO from an executable, you may want to create DLLs for distribution so that others can use them in their applications. If so, then you are responsible for starting 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 EXE, 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 app
// this case hangs
__declspec(dllexport) void hello()
{
}
#else
// when this is built as a console app, 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. You could do this as part of other initialization, for example. In other words, if you declare the global variable as a pointer to CdbDBEngine, then construct the class in your initialization function.