CDatabase == CRASH?!
David Warness -- david@emerald.CyberGate.COM
Monday, July 22, 1996
Environment: VC++ 4.2/Win 95
Has anyone had any problems with the class CDatabase causing illegal
instruction errors when an application exits? I've noticed that just the
opening of a CDatabase, and a close will randomly cause this error after
the application has appeared to have finished exiting. (The window is
gone, but windows reports that the application caused the error)
The Debug version of the application running on the debugger will *NOT*
cause the crash. The Debug version not running on the debugger sometimes
causes a crash. The Release version causes a crash the 2nd time the
application is run, and then closed.
Am I alone with this problem? I've also verified that the Microsoft
example daeview has the same problems. This leads me to believe that
it's an error in the MFC library. Are there any work arounds?
-Dave
+--------------------------------------------------------------------------+
| David Warness | Psychiatrists say that one out of four people are |
| Look for me at ... | mentally ill. Check three friends. If they're ok, |
| david@CyberGate.COM | you're it! |
+--------------------------------------------------------------------------+
Benny -- blee@filenet.com
Thursday, July 25, 1996
[Mini-digest: 4 responses]
Dave,
I had something similar.
With NT Beta 2, using the access ODBC driver causes a GPF within the cursor
library. However, if I change it to use the SQL Server backend, the problem
went away. My conclusion was that either I have bugs in my code or that
there are bugs in the access ODBC driver - currently I am leaning toward the
latter.
Which platform and database are you using?
[Moderator's note: It says Win95, so there's half the answer.]
Benny
----------
Environment: VC++ 4.2/Win 95
Has anyone had any problems with the class CDatabase causing illegal
instruction errors when an application exits? I've noticed that just the
opening of a CDatabase, and a close will randomly cause this error after
the application has appeared to have finished exiting. (The window is
gone, but windows reports that the application caused the error)
The Debug version of the application running on the debugger will *NOT*
cause the crash. The Debug version not running on the debugger sometimes
causes a crash. The Release version causes a crash the 2nd time the
application is run, and then closed.
Am I alone with this problem? I've also verified that the Microsoft
example daeview has the same problems. This leads me to believe that
it's an error in the MFC library. Are there any work arounds?
-Dave
+--------------------------------------------------------------------------+
| David Warness | Psychiatrists say that one out of four people are |
| Look for me at ... | mentally ill. Check three friends. If they're ok, |
| david@CyberGate.COM | you're it! |
+--------------------------------------------------------------------------+
-----From: stanleyh (Stanley Man-Kit Ho)
Hi,
Are you creating a CDatabase object dynamically?? I have a similar
problem long time ago when I "new" a CDatabase at the beginning and "delete"
it at the end of the program, and the program crashes afterward. In my case,
I solve it by assigning the CDatabase pointer to NULL.
Stanley 8^)
--
______________________________________________________________________________
Stanley Man-Kit Ho Email: stanleyh@netcom.com
Internet Commerce Division, Novell. mho@novell.com
WWW: http://www.novell.com Running Windows 95/NT, OS/2 Warp
______________________________________________________________________________
-----From: "Andrew Lazarus"
I have had trouble with CDaoDatabase when objects were created on the
stack and/or default objects were created (e.g., the CDaoWorkspace
getting created automatically when the CDaoDatabase is).
Errors went away when I created the CDaoDatabase on the heap and
stored a ptr in my CWinApp, then explicitly deleted it in
ExitInstance.
I think some of the fields get destroyed twice when default objects
are used AND dtors are called implicitly, e.g. when the object (not
a ptr) is a member and it gets destroyed in CWinApp::~CWinApp.
HTH
Andrew Lazarus
Sr Software Engineer
-----From: Dan Kirby
There is Jet problem. You can see the same problem with the MFC Access
ODBC driver but not as frequently. To work around the problem, I found
that you can do a LoadLibrary call on MSJet3032.dll after you open the
database, you won't see the problem. Don't bother calling FreeLibrary.
Basically the additional ref count on the DLL keeps it loaded during the
shut-down process and avoids problems with the Jbet engine. This problem
only occurs on Win95.
--dan
| Вернуться в корень Архива
|