DLL + DAO = TROUBLE

Warren Bedell -- wbedell@mindspring.com
Friday, February 23, 1996

I'm trying to use the VC 4.0 DAO classes in an AppWizard generated DLL
and having nothing but trouble.  I followed a related thread here and
read the KB article Q143084 "BUG: Problems with Using the MFC DAO Classes
in a .DLL or .OCX", and I think I have followed all of the suggestions.

I have tried a global pointer to a CDaoDatabase object as well as a local
pointer within the DLL function.  In both cases I get the same result - an
Accsess Violation which ultimately requires rebooting Windows 95!  In the
debugger output window I get the following messages when the EXE calling
the DLL terminates (I don't get any odd messages from the DLL itself):

    The thread 0xFFD36C9 has terminated with code -1 (0xFFFFFFFF)
    The thread ...
    The thread ...
    First Chance Exception in DMPDebug.EXE (MSJT3032.DLL): 0xC0000005:
        Access Violation
    Program has exited with code 0 (0x0)

The DLL function does nothing more than new on the pointer, open the
database, close the database and delete the pointer.  If I put the same
code in a standalone EXE without the DLL it works fine.  The three thread
messages all terminate with codes of 0 and there is no exception/access
violation.

I've tried avery combination I can think of, so either I'm missing
something (which is highly possible) or the problems with DAO classes in
a DLL make the combination unworkable.

Has anyone actually gotten the DAO classes to work in a DLL?  If so,
could you email me some code samples to get me started?  If not, what
other alternatives do I have?  I'm investigating an OLE Automation Server
approach, but that's introducing a lot of learning overhead into the
project which I really can't afford.  So, any ideas and assistance will
be *greatly* appreciated.

TIA,

--
Warren Bedell
wbedell@mindspring.com

PS.  In case it'll help, here's the function I'm using:

long Check(void)
{
    CDaoDatabase *    	pDB;
    int                 rc = 0;

    pDB = new CDaoDatabase;

    if (!OpenDB(pDB, "G:\\DMA\\DATAMAIL.MDB")) {
        TRACE0("    Check() aborted - unable to open database\n");
        rc = 1;
    }

    pDB->Close();

    delete pDB;

    TRACE0("    Check() ending\n");

    return(rc);
}

---

Mike Blaszczak -- mikeblas@interserv.com
Sunday, February 25, 1996

On Fri, 23 Feb 96, Warren Bedell  wrote:

>In the
>debugger output window I get the following messages when the EXE calling
>the DLL terminates (I don't get any odd messages from the DLL itself):
>
>    The thread 0xFFD36C9 has terminated with code -1 (0xFFFFFFFF)
>    The thread ...
>    The thread ...
>    First Chance Exception in DMPDebug.EXE (MSJT3032.DLL): 0xC0000005:
>        Access Violation
>    Program has exited with code 0 (0x0)
>

This symptom makes it sound, to me, like you're having too many people 
initalize OLE.  When I've written code that initializes OLE from more than 
one thread in a process, or initializes OLE from one thread and calls into 
OLD from another, I've seen similar behaviour.

.B ekiM
--
TCHAR szFreeSoda[] = _T("Ask me how you can get a job at Microsoft.");

---

Glenn T. Jayaputera -- gtj@nunkeen.apana.org.au
Tuesday, February 27, 1996

> >In the
> >debugger output window I get the following messages when the EXE calling
> >the DLL terminates (I don't get any odd messages from the DLL itself):
> >
> >    The thread 0xFFD36C9 has terminated with code -1 (0xFFFFFFFF)
> >    The thread ...
> >    The thread ...
> >    First Chance Exception in DMPDebug.EXE (MSJT3032.DLL): 0xC0000005:
> >        Access Violation
> >    Program has exited with code 0 (0x0)
> >
> 
> This symptom makes it sound, to me, like you're having too many people 
> initalize OLE.  When I've written code that initializes OLE from more than 
> one thread in a process, or initializes OLE from one thread and calls into 
> OLD from another, I've seen similar behaviour.

I have similar problem too, this is true if  the DLL is _regular_ type (static or  
shared), but not if it is extension DLL.

What I found is the DLL client (EXE) has to create the database in the global heap 
thus not the DLL itself. I dont know why and I am still searching for the answer 
and solution...

Therefore in your DLL you should have something like

__declspec( dllexport ) CDaoDatabase *pDb;

:
:
:



And hence in your EXE you should have

__declspec( dllimport ) CDaoDatabase *pDb;

CMyApp::InitInstance()
{
   pDb = new CDaoDatabase;
   :
   :
}

CMyApp::ExitInstance()
{
   delete pDb;
   pDb = NULL;
   :
}


This should be okay if you are planning to use your DLL only with the apps you are 
writing, but if you are planning to let others to use then big no no....
My problem is I am creating Excel addin and hence there is no way I can tell Excel 
to do 
      new CDaoDatabase;

I am still searching for the real solution to this problem so if somebody has 
solved this problem please share with us

thanks
glenn tesla

---

| Вернуться в корень Архива |