By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,135 Members | 1,135 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,135 IT Pros & Developers. It's quick & easy.

Access won't close after using DLL

P: n/a
I have an Access MDB which instantiates a class in a custom DLL, manipulates
it for a while, then sets it equal nothing.
The MDB does other things,too, and generally behaves itself as desired.
But, if I have done the DLL thing, even though I close the MDB, Access
refuses to close.
If I haven't used the DLL, all is well.

The DLL is one I wrote myself in VB.

I'm quite stumped, and rather guess the problem may be in the DLL (I've also
posted in a VB group), but since the symptoms are in Access, I thought I'd
ask here if anybody has seen anything like this.

TIA!
- Turtle
Nov 13 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Are you passing a reference to a Form in your custom class that you are
forgetting to release before/during the Terminate event of your class?
Are you sure the Terminate/Cleanup event of your custom class is being
called?

What operations are performed in your class?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"MacDermott" <ma********@nospam.com> wrote in message
news:77******************@newsread3.news.atl.earth link.net...
I have an Access MDB which instantiates a class in a custom DLL, manipulates it for a while, then sets it equal nothing.
The MDB does other things,too, and generally behaves itself as desired. But, if I have done the DLL thing, even though I close the MDB, Access
refuses to close.
If I haven't used the DLL, all is well.

The DLL is one I wrote myself in VB.

I'm quite stumped, and rather guess the problem may be in the DLL (I've also posted in a VB group), but since the symptoms are in Access, I thought I'd ask here if anybody has seen anything like this.

TIA!
- Turtle


Nov 13 '05 #2

P: n/a
Good to see you in here, Stephen!

My class does indeed hold a reference, but it's to another class (this one
written in VB.NET) that it creates in its Initialize event and sets to
Nothing in its Terminate event.
I think of the VB class as a wrapper for the VB.NET class. The VB class
takes the PK and retrieves data from the stored data (an Access database),
creating a disconnected ADO recordset, which it passes to the VB.NET class.
(No connections are ever held open.) The VB class then receives updates to
this data, which it stores in the recordset and passes on to the VB.NET
object. When so requested, it writes this data back to the stored data.
When requested, it gets calculations performed by the VB.NET module and
returns them as its properties.

The only data I pass into the class is in the form of single-valued
variables.
I don't pass any references to Forms around; the graphic interface (which in
this case is very simple) is all done in the base Access MDB.

I destroy the custom class (the VB class) from Access by setting it to
Nothing.
And yes, I have put a breakpoint in the Terminate event - it is being
called.
The odd thing about it is this:
I can remove the breakpoint and press F8 to continue execution. When I
do that, the yellow highlight disappears, but I can't get back to the
original Access application. When I click the Break key on the toolbar, the
code breaks again in exactly the same place it was before.
However, if I don't have a breakpoint in the Terminate event, execution
returns to the Access application and everything looks normal - until I try
to exit Access.

I spent several frustrating hours with this yesterday, covering a lot of
details, and I don't know which ones are relevant to finding a solution.
Another one I should probably mention is that we were able to reproduce this
"error" (Access won't close) on one other PC, but not on another. So we
have 2 PCs that display it, and 2 that don't.
I don't want to ramble on about a lot of other things which may or may not
be relevant, but I very much appreciate your questions, which help focus on
which aspects of this beast I should be looking at.

- Turtle

"Stephen Lebans" <Fo****************************************@linval id.com>
wrote in message news:Ox*********************@ursa-nb00s0.nbnet.nb.ca...
Are you passing a reference to a Form in your custom class that you are
forgetting to release before/during the Terminate event of your class?
Are you sure the Terminate/Cleanup event of your custom class is being
called?

What operations are performed in your class?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"MacDermott" <ma********@nospam.com> wrote in message
news:77******************@newsread3.news.atl.earth link.net...
I have an Access MDB which instantiates a class in a custom DLL,

manipulates
it for a while, then sets it equal nothing.
The MDB does other things,too, and generally behaves itself as

desired.
But, if I have done the DLL thing, even though I close the MDB, Access
refuses to close.
If I haven't used the DLL, all is well.

The DLL is one I wrote myself in VB.

I'm quite stumped, and rather guess the problem may be in the DLL

(I've also
posted in a VB group), but since the symptoms are in Access, I thought

I'd
ask here if anybody has seen anything like this.

TIA!
- Turtle

Nov 13 '05 #3

P: n/a
What happens when you comment out the code that instantiates the VB.NET
class? Is the bug still reproducable?

I have done very little with VB.NET Turtle so if this is a VB.NET ->
VB -> AccessVBA interaction issue I would be of little help resolving
this issue.
--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"MacDermott" <ma********@nospam.com> wrote in message
news:jr*****************@newsread3.news.atl.earthl ink.net...
Good to see you in here, Stephen!

My class does indeed hold a reference, but it's to another class (this one written in VB.NET) that it creates in its Initialize event and sets to
Nothing in its Terminate event.
I think of the VB class as a wrapper for the VB.NET class. The VB class takes the PK and retrieves data from the stored data (an Access database), creating a disconnected ADO recordset, which it passes to the VB.NET class. (No connections are ever held open.) The VB class then receives updates to this data, which it stores in the recordset and passes on to the VB.NET object. When so requested, it writes this data back to the stored data. When requested, it gets calculations performed by the VB.NET module and returns them as its properties.

The only data I pass into the class is in the form of single-valued
variables.
I don't pass any references to Forms around; the graphic interface (which in this case is very simple) is all done in the base Access MDB.

I destroy the custom class (the VB class) from Access by setting it to
Nothing.
And yes, I have put a breakpoint in the Terminate event - it is being called.
The odd thing about it is this:
I can remove the breakpoint and press F8 to continue execution. When I do that, the yellow highlight disappears, but I can't get back to the
original Access application. When I click the Break key on the toolbar, the code breaks again in exactly the same place it was before.
However, if I don't have a breakpoint in the Terminate event, execution returns to the Access application and everything looks normal - until I try to exit Access.

I spent several frustrating hours with this yesterday, covering a lot of details, and I don't know which ones are relevant to finding a solution. Another one I should probably mention is that we were able to reproduce this "error" (Access won't close) on one other PC, but not on another. So we have 2 PCs that display it, and 2 that don't.
I don't want to ramble on about a lot of other things which may or may not be relevant, but I very much appreciate your questions, which help focus on which aspects of this beast I should be looking at.

- Turtle

"Stephen Lebans" <Fo****************************************@linval id.com> wrote in message

news:Ox*********************@ursa-nb00s0.nbnet.nb.ca...
Are you passing a reference to a Form in your custom class that you are forgetting to release before/during the Terminate event of your class? Are you sure the Terminate/Cleanup event of your custom class is being called?

What operations are performed in your class?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"MacDermott" <ma********@nospam.com> wrote in message
news:77******************@newsread3.news.atl.earth link.net...
I have an Access MDB which instantiates a class in a custom DLL,

manipulates
it for a while, then sets it equal nothing.
The MDB does other things,too, and generally behaves itself as

desired.
But, if I have done the DLL thing, even though I close the MDB, Access refuses to close.
If I haven't used the DLL, all is well.

The DLL is one I wrote myself in VB.

I'm quite stumped, and rather guess the problem may be in the DLL

(I've also
posted in a VB group), but since the symptoms are in Access, I
thought I'd
ask here if anybody has seen anything like this.

TIA!
- Turtle



Nov 13 '05 #4

P: n/a
Hi, Stephen!

Thanks for that very relevant idea!
Unfortunately, from here I can only VPN into a PC which doesn't exhibit the
problem - not to one that does.
So I'll try your idea when I get to work on Monday.

Since the VB.NET part is entirely wrapped in the VB part, and works
flawlessly in another application, I'll be surprised if that turns out to be
the problem.
My guess is that it's my shaky understanding of COM objects in general that
has led to this problem.

And if it does turn out to be a .NET interaction issue -
there are lots of newsgroups I can turn to.
One thing about a newer technology is that there are plenty of folks
eager to talk about it.
(Ever try to find a Pascal editor?)

I'll let you know what I turn up Monday.
- Turtle

"Stephen Lebans" <Fo****************************************@linval id.com>
wrote in message news:Rq*********************@ursa-nb00s0.nbnet.nb.ca...
What happens when you comment out the code that instantiates the VB.NET
class? Is the bug still reproducable?

I have done very little with VB.NET Turtle so if this is a VB.NET ->
VB -> AccessVBA interaction issue I would be of little help resolving
this issue.
--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"MacDermott" <ma********@nospam.com> wrote in message
news:jr*****************@newsread3.news.atl.earthl ink.net...
Good to see you in here, Stephen!

My class does indeed hold a reference, but it's to another class (this

one
written in VB.NET) that it creates in its Initialize event and sets to
Nothing in its Terminate event.
I think of the VB class as a wrapper for the VB.NET class. The VB

class
takes the PK and retrieves data from the stored data (an Access

database),
creating a disconnected ADO recordset, which it passes to the VB.NET

class.
(No connections are ever held open.) The VB class then receives

updates to
this data, which it stores in the recordset and passes on to the

VB.NET
object. When so requested, it writes this data back to the stored

data.
When requested, it gets calculations performed by the VB.NET module

and
returns them as its properties.

The only data I pass into the class is in the form of single-valued
variables.
I don't pass any references to Forms around; the graphic interface

(which in
this case is very simple) is all done in the base Access MDB.

I destroy the custom class (the VB class) from Access by setting it to
Nothing.
And yes, I have put a breakpoint in the Terminate event - it is

being
called.
The odd thing about it is this:
I can remove the breakpoint and press F8 to continue execution.

When I
do that, the yellow highlight disappears, but I can't get back to the
original Access application. When I click the Break key on the

toolbar, the
code breaks again in exactly the same place it was before.
However, if I don't have a breakpoint in the Terminate event,

execution
returns to the Access application and everything looks normal - until

I try
to exit Access.

I spent several frustrating hours with this yesterday, covering a lot

of
details, and I don't know which ones are relevant to finding a

solution.
Another one I should probably mention is that we were able to

reproduce this
"error" (Access won't close) on one other PC, but not on another. So

we
have 2 PCs that display it, and 2 that don't.
I don't want to ramble on about a lot of other things which may or may

not
be relevant, but I very much appreciate your questions, which help

focus on
which aspects of this beast I should be looking at.

- Turtle

"Stephen Lebans"

<Fo****************************************@linval id.com>
wrote in message

news:Ox*********************@ursa-nb00s0.nbnet.nb.ca...
Are you passing a reference to a Form in your custom class that you are forgetting to release before/during the Terminate event of your class? Are you sure the Terminate/Cleanup event of your custom class is being called?

What operations are performed in your class?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"MacDermott" <ma********@nospam.com> wrote in message
news:77******************@newsread3.news.atl.earth link.net...
> I have an Access MDB which instantiates a class in a custom DLL,
manipulates
> it for a while, then sets it equal nothing.
> The MDB does other things,too, and generally behaves itself as
desired.
> But, if I have done the DLL thing, even though I close the MDB, Access > refuses to close.
> If I haven't used the DLL, all is well.
>
> The DLL is one I wrote myself in VB.
>
> I'm quite stumped, and rather guess the problem may be in the DLL
(I've also
> posted in a VB group), but since the symptoms are in Access, I thought I'd
> ask here if anybody has seen anything like this.
>
> TIA!
> - Turtle
>
>


Nov 13 '05 #5

P: n/a
Many thanks for all of the help I've received on this issue.
I certainly don't have a full understanding of what's going on here, but I
have enough greater understanding to be able to work around this phenomenon,
so I thought I'd at least record what I've found -
just in case it helps someone else.

My structure was this:
Access creates a class instance defined in VB6.0. (Test)
The VB6.0 class creates instance of another class defined in VB.NET.
(NETTest)
The VB6.0 exposes the VB.NET class instance as a property.
Thus, from Access, I can evaluate properties of the VB.NET class instance,
e.g. Test.NETTest.Volume.
Or so it would seem - and I can actually execute this code.
But if I do this, then close the Access MDB, Access itself will not
close.

If, instead, I define a property of the VB6.0 class:
Public Property Get TVolume() as Double
TVolume=NETTest.Volume
End Property

I can evaluate Test.TVolume. I get the same value as when I use
Test.NETTest.Volume, but this time I can close Access.

If anyone has any light to shed on this, I'd be grateful -
but mostly I'm glad it's working again.

- Turtle

BTW if I instantiate the VB6.0 class from VB, instead of from Access, I
haven't experienced this problem.
"MacDermott" <ma********@nospam.com> wrote in message
news:77******************@newsread3.news.atl.earth link.net...
I have an Access MDB which instantiates a class in a custom DLL, manipulates it for a while, then sets it equal nothing.
The MDB does other things,too, and generally behaves itself as desired.
But, if I have done the DLL thing, even though I close the MDB, Access
refuses to close.
If I haven't used the DLL, all is well.

The DLL is one I wrote myself in VB.

I'm quite stumped, and rather guess the problem may be in the DLL (I've also posted in a VB group), but since the symptoms are in Access, I thought I'd
ask here if anybody has seen anything like this.

TIA!
- Turtle

Nov 13 '05 #6

P: n/a
Thanks for all your comments, Rich!

This application was originally done with the calculations in VB.NET, and
the GUI in VB6.0 - for reasons buried in history.
I built the calculations module as a class object, so I can populate some of
its properties with my input variables, then query other properties to
return the results of the calculations.
It then became clear that the application needed to track a whole bunch more
"properties" of this class, which were not needed in the calculations. (a
simple analogy - if my .NET class took a person's age and sex, and a policy
amount, it could calculate a life insurance premium. The application also
needs to track the person's first name, last name, and SSN, but these aren't
required in the calculations module.)
Thus a "wrapper" class was born. The wrapper class also does all of the
database interaction. (using an Access MDB.) The wrapper class was written
in VB6.0 because that made it especially easy to interact with the VB6.0
GUI.

As you can see, this model works very well for single records. Enter data -
perform calculations - print report for that record. A single record can be
retrieved, the classes re-populated, and the calculations redone.

Late in the process, the client requested that he also be able to retrieve
records in bulk - in a format significantly different from the current
database format. For one thing, he wanted many of the results of the
calculations to be stored in this new "bulk" format. For this, the fancy
GUI was not required, so for rapid development we decided to use an Access
database. This application loops through the records in the database,
retrieving each, populating the classes, then reads the calculated values
out and puts them into a new table. Since all of the code to retrieve data
and populate the classes existed in the VB6.0 "wrapper" dll, it made sense
to use that, rather than write something new.
All of this worked fine, with one exception. I needed to record the
results of a calculation which the VB.NET dll exposed to the VB6.0 wrapper,
but which up until then had only been used internally in the VB6.0 dll, but
not exposed for outside use. However, I HAD exposed the VB.NET class itself
as a property of the VB6.0 dll. So I simply queried the relevant property
of the VB.NET class as a property of the VB6.0 class.
Did I say simply? When I traced it down, I found that this was what was
causing my problems. As soon as I rewrote the VB6.0 dll, adding a property
which returned the VB.NET class property I needed, all was well.

So in a sense the problem is solved. But I sure don't feel I understand
it all especially well.
- Turtle


"Rich P" <rp*****@aol.com> wrote in message
news:40*********************@news.newsgroups.ws...
If I understand your problem correctly, you are wrapping a vb.net class
in a vb6 wrapper and invoking this in Access? I see a couple of issues
with this scenario right off the bat (with all due respect). 1st, why
wrapt the vb.net class in VB6? How about just writing your dll straight
in vb.net (very easy and more robust than a vb6 activeX dll - not nearly
as touchy as the vb6 dll). 2nd, if you did not write the vb.net class,
then the problem is in the vb.net class. The vb.net class is probably
correct, but having a middle layer (vb6 wrapper) may require some
additional configuring of the vb.net class (here vb.net is a bit more
touchy than vb6 - in configuring). Oh yeah, make sure you have the
dotnet framework installed on the machine (incase it isn't).

As for making the vb.net class interoperable with com (Access is com) in
the vb.net projet properties dialog box goto configuration
properties/build/ and check all of the check boxes (especially the
"Register for Com Interop" check box). Then rebuild/recompile. And as
long as you do that, this will create a dll and a tlb file. Make a
reference to the tlb file (library file) in Access and forgo your vb6
wrapper.

Either way, you will have to get into the code of your vb.net class to
solve your problem. while you are there why not bypass vb6 altogether?
My rule of thumb is that if you can avoid the middle layer (not like a
middle tier) that is one less thing you have to deal with.

I have actually had more success with vb.net dlls with Access than
ActiveX dlls from vb6. VB.net dlls are real dlls but you don't have to
declare them like a C dll (API call) since VBA and VB.net are still VB
(sort of).

Rich

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 13 '05 #7

P: n/a
"MacDermott" <ma********@nospam.com> wrote:
I certainly don't have a full understanding of what's going on here, but I
have enough greater understanding to be able to work around this phenomenon,
so I thought I'd at least record what I've found -
just in case it helps someone else.


Very interesting. Thanks for posting back.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #8

P: n/a
Hi Tony,
This is completely OT for this thread but I lost you!

For some reason I don't get a reply from you anymore on our last-week-mails regarding Startmdb and
Access 2.0
I did send you a couple of emails (reply on your last mail about the topic) last week to no avail.
There must be *something* wrong ...

I would be glad to here *anything* from you.

Thanks
Arno R


"Tony Toews" <tt****@telusplanet.net> schreef in bericht
news:sl********************************@4ax.com...
"MacDermott" <ma********@nospam.com> wrote:
I certainly don't have a full understanding of what's going on here, but I
have enough greater understanding to be able to work around this phenomenon,
so I thought I'd at least record what I've found -
just in case it helps someone else.


Very interesting. Thanks for posting back.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Nov 13 '05 #9

P: n/a
"Arno R" <ar****************@tiscali.nl> wrote:
This is completely OT for this thread but I lost you!

For some reason I don't get a reply from you anymore on our last-week-mails regarding Startmdb and
Access 2.0
I did send you a couple of emails (reply on your last mail about the topic) last week to no avail.
There must be *something* wrong ...

I would be glad to here *anything* from you.


Sorry. I get a lot of emails and sometimes lose track of them. I want to get to
your Auto FE Updater problem later today or tomorrow.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.