If you have the code for both the caller and the dll, you can debug the dll. Also, you could use an error reporting tool like Eurekalog to get a more informative message.
I use TADOConnection extensively, and do not always close it before freeing it.
Never have this problem. And I don't think dll-ness is a factor.
jhg
-----Original Message-----
From: advanced_delphi@yahoogroups.com on behalf of David Smith
Sent: Thu 1/31/2008 7:04 AM
To: advanced_delphi@yahoogroups.com
Subject: Re: [advanced_delphi] TADOConnection causing Access Violation
Do you close the connection before freeing the DLL?
ai_no_kareshi <[EMAIL PROTECTED]> wrote: To
simplify things, I've written a very basic program which
dynamically loads an external DLL (using LoadLibrary with the text
from an Edit control as the filename), then frees it again (using
FreeLibrary). Only when I close the form, I sometimes get an access
violation, depending on the DLL loaded.
After some testing, I have determined that the access violation only
occurs when the DLL creates an instance of TADOConnection. It does not
seem to make a difference what values are assigned to the connection
object's properties, and the error occurs regardless of whether it is
created in runtime or design time (through a data module). Note that I
only experience this using a DLL; I have never had any trouble using a
TADOConnection in a standalone executable.
Has anyone else run into this error? Is there something fundamentally
wrong with the TADOConnection object that makes it unusable in
situations like this? Can anyone suggest a solution?
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
<<winmail.dat>>
