Re: VB DLL won't die

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: MacDermott (macdermott_at_NoSpam.com)
Date: 06/09/04


Date: Tue, 8 Jun 2004 22:32:28 -0400

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" <macdermott@NoSpam.com> wrote in message
news:OBGSDzqSEHA.556@tk2msftngp13.phx.gbl...
> I'm posting this question here because I *think* the problem is in the VB
> part of the story, but also because I've gotten such spectacular help here
> on other issues.
> I'll also put something similar in an Access newsgroup, but if somebody
else
> knows another, perhaps better newsgroup for this question, please let me
> know.
>
> Here goes:
> I have a VB DLL which I wrote as part of a VB application. It does a fair
> bit of data manipulation, including reading and writing to an Access
> database. I've been asked to provide a trimmed-down version, with very
> little of the VB graphic interface, and more intensive database
interaction.
> The simple approach seemed to be to use an Access front end, which calls
the
> VB DLL to "do the work" and stores the data back into its own tables.
> I create an instance of a class from the DLL, and a DAO recordset,
then
> I keep feeding the class PKs from the recordset, which it uses to read
data
> into the class, do the calculations, and write them out into a new table.
> At the end, I set the instance = nothing and close up shop.
>
> This was all working fine on my development machine, but then I moved it
> onto a target (production) machine, only to find that Access wouldn't
close.
> I could close the database, but the only way I could get Access itself to
> close was with the Task Manager.
> We tried further, and got it to work well on one other machine, and to
> generate the problem on another.
> The machines where it doesn't work have slightly slower CPUs, perhaps
> slightly less RAM, and for the record are panel PCs, although I can't see
> what difference that would make.
>
> On one of the panel PCs, I opened the DLL's project and ran it in the
> debugger. From there I started Access and ran my application. I put a
> break point in the DLL class's Terminate event. To my amazement, once I
had
> stopped execution there, I couldn't seem to get out of that event. I
> removed the breakpoint and pressed F8. The yellow highlight went away,
but
> I couldn't get back to the Access application. If I hit the Break button
on
> the menu, the yellow highlight would come back to the same line of code
> where it had been. I could manually move execution down a line and repeat
> the sequence - the highlight came back on the new line.
>
> Any ideas what could be causing this?
> - Turtle
>
>



Relevant Pages

  • Re: VB DLL wont die
    ... little of the VB graphic interface, and more intensive database interaction. ... VB DLL to "do the work" and stores the data back into its own tables. ... I keep feeding the class PKs from the recordset, which it uses to read data ... the yellow highlight would come back to the same line of code ...
    (microsoft.public.vb.general.discussion)
  • VB DLL wont die
    ... little of the VB graphic interface, and more intensive database interaction. ... VB DLL to "do the work" and stores the data back into its own tables. ... I keep feeding the class PKs from the recordset, which it uses to read data ... the yellow highlight would come back to the same line of code ...
    (microsoft.public.vb.general.discussion)
  • POS/ COGNOS/ CAREER POSITION/ OH
    ... repositories needed to support the Company's business objectives. ... *Proficient in Microsoft technologies, including MS Access, MS Office Suite. ... *Experience and understanding of application servers. ... *Experience and understanding of database servers. ...
    (comp.sys.ibm.as400.misc)
  • Re: AD+ crash logs and .dmps Part II
    ... This a .dll provided by an online payment verification ... The Debugger docs have some basic info but overall, understanding ... details the formation and usage of the stack. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Public Function dbLocal
    ... understanding the functionality of the more obscure tricks of the trade. ... opened database (initialized by a call to CurrentDB() if necessary), ... "If you can't laugh at yourself, ...
    (comp.databases.ms-access)