|
|
Here the whole story: We have a programfile A.mdb (Version: MSAccess 2003),
which instanciates a COM component B.dll, which in turn instanciates C.dll.
In C.dll, we do some database manipulations in an SQL server database,
therefore we create a workspace like follows:
set mwspDAO = DBEngine.CreateWorkspace("wspData", "", "", dbUseODBC)
Later when A.mdb should terminate (with the command: application.quit),
MSAccess has problems, it does not close. Depending whether the whole thing
is in a full access or a runtime environment, the Access main window shortly
disappears and reappears and then flashes several times per second, or it
comes a message that the program has stopped because of a runtime error, but
there is never possible to close it.
I did the following test (test #1): After the "CreateWorkspace" I skip the
main actions of C.dll and do only terminating actions. The problems with
A.mdb remain
In test #2 I do NOT execute the "CreateWorkspace", everything else is equal
like test #1. Then with Access the terminating problem has disappeared. So I
thought that the workspace must be the "heart" of the problem.
In test #3 I execute the "CreateWorkspace" and then additionally execute the
following 2 lines:
mwspDAO.Close
Set mwspDAO = Nothing
(and the rest again equal to test #1). The terminating problem with Access
again arises like in test #1. I don't grasp that. What is the difference
between test #2 and test #3? If I close the workspace and set it to nothing,
what can be the difference to the situation where I never instanciate the
workspace? Are there "stronger" methods to destroy DAO objects, or what can
be done here to solve this problem?
|
|
You are using DBEngine in C.dll?
Show the code that creates the DBEngine object.
What code do you have that closes the dbengine object?
CreateWorkspace will create threads. You aren't doing this inside a
thread instatiation are you?
Can you try creating object B from a different program? Does B close
cleanly when Access is not open? when access is open but in a different
process?
(david)
Lorenz Ingold wrote:
[Quoted Text] > Here the whole story: We have a programfile A.mdb (Version: MSAccess 2003),
> which instanciates a COM component B.dll, which in turn instanciates C.dll.
> In C.dll, we do some database manipulations in an SQL server database,
> therefore we create a workspace like follows:
> set mwspDAO = DBEngine.CreateWorkspace("wspData", "", "", dbUseODBC)
> Later when A.mdb should terminate (with the command: application.quit),
> MSAccess has problems, it does not close. Depending whether the whole thing
> is in a full access or a runtime environment, the Access main window shortly
> disappears and reappears and then flashes several times per second, or it
> comes a message that the program has stopped because of a runtime error, but
> there is never possible to close it.
> I did the following test (test #1): After the "CreateWorkspace" I skip the
> main actions of C.dll and do only terminating actions. The problems with
> A.mdb remain
> In test #2 I do NOT execute the "CreateWorkspace", everything else is equal
> like test #1. Then with Access the terminating problem has disappeared. So I
> thought that the workspace must be the "heart" of the problem.
> In test #3 I execute the "CreateWorkspace" and then additionally execute the
> following 2 lines:
> mwspDAO.Close
> Set mwspDAO = Nothing
> (and the rest again equal to test #1). The terminating problem with Access
> again arises like in test #1. I don't grasp that. What is the difference
> between test #2 and test #3? If I close the workspace and set it to nothing,
> what can be the difference to the situation where I never instanciate the
> workspace? Are there "stronger" methods to destroy DAO objects, or what can
> be done here to solve this problem?
>
>
|
|
I do never create the DBEngine object. This is available because I have set
a reference to "Microsoft DAO 3.6 Object Library". DBEngine seems to have
the value "GlobalMultiUse" of the instancing property. The same is with
terminating: I do nothing about this (no closing or setting to nothing).
How can we use threads in VB6? I thought this is not possible (at least I
never used it).
We had earlier used an A.exe (a VB6 Standard Exe) to call B.dll, instead of
A.mdb calling B.dll. The A.exe closes properly, we never had the terminating
problems here. But this is not the comfort we want for the user: The A.exe
is then used like an external tool which must be called separately. The user
wants to work only with A.mdb.
I could perhaps try to call A.exe from A.mdb, then it should be in a
different process (is this true?). How can then A.mdb see when the process
of A.exe has finished?
"DAVID" <david[ at ]nospam.nspam> wrote in message
news:eRaLzlSuHHA.2752[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text] > You are using DBEngine in C.dll?
> Show the code that creates the DBEngine object.
>
> What code do you have that closes the dbengine object?
>
> CreateWorkspace will create threads. You aren't doing this inside a thread
> instatiation are you?
>
> Can you try creating object B from a different program? Does B close
> cleanly when Access is not open? when access is open but in a different
> process?
>
> (david)
>
>
>
> Lorenz Ingold wrote:
>> Here the whole story: We have a programfile A.mdb (Version: MSAccess
>> 2003), which instanciates a COM component B.dll, which in turn
>> instanciates C.dll. In C.dll, we do some database manipulations in an SQL
>> server database, therefore we create a workspace like follows:
>> set mwspDAO = DBEngine.CreateWorkspace("wspData", "", "", dbUseODBC)
>> Later when A.mdb should terminate (with the command: application.quit),
>> MSAccess has problems, it does not close. Depending whether the whole
>> thing is in a full access or a runtime environment, the Access main
>> window shortly disappears and reappears and then flashes several times
>> per second, or it comes a message that the program has stopped because of
>> a runtime error, but there is never possible to close it.
>> I did the following test (test #1): After the "CreateWorkspace" I skip
>> the main actions of C.dll and do only terminating actions. The problems
>> with A.mdb remain
>> In test #2 I do NOT execute the "CreateWorkspace", everything else is
>> equal like test #1. Then with Access the terminating problem has
>> disappeared. So I thought that the workspace must be the "heart" of the
>> problem.
>> In test #3 I execute the "CreateWorkspace" and then additionally execute
>> the following 2 lines:
>> mwspDAO.Close
>> Set mwspDAO = Nothing
>> (and the rest again equal to test #1). The terminating problem with
>> Access again arises like in test #1. I don't grasp that. What is the
>> difference between test #2 and test #3? If I close the workspace and set
>> it to nothing, what can be the difference to the situation where I never
>> instanciate the workspace? Are there "stronger" methods to destroy DAO
>> objects, or what can be done here to solve this problem?
>>
|
|
Hi,
seems that you are passing some object reference to you dll and holding
there. you need to store pointer to it instead. here a code from my dll,
access.application property:
Public Property Set AccApplication(ByVal oAccess As Object)
mpAccess = ObjPtr(oAccess)
End Property
Public Property Get AccApplication() As Object
Dim oTemp As Object
CopyMemory oTemp, mpAccess, 4
Set AccApplication = oTemp
CopyMemory oTemp, 0&, 4
End Property
--
Best regards,
___________
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com
"Lorenz Ingold" <l.ingold[ at ]winvs.ch> wrote in message
news:OfAAURJuHHA.4916[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > Here the whole story: We have a programfile A.mdb (Version: MSAccess
> 2003), which instanciates a COM component B.dll, which in turn
> instanciates C.dll. In C.dll, we do some database manipulations in an SQL
> server database, therefore we create a workspace like follows:
> set mwspDAO = DBEngine.CreateWorkspace("wspData", "", "", dbUseODBC)
> Later when A.mdb should terminate (with the command: application.quit),
> MSAccess has problems, it does not close. Depending whether the whole
> thing is in a full access or a runtime environment, the Access main window
> shortly disappears and reappears and then flashes several times per
> second, or it comes a message that the program has stopped because of a
> runtime error, but there is never possible to close it.
> I did the following test (test #1): After the "CreateWorkspace" I skip the
> main actions of C.dll and do only terminating actions. The problems with
> A.mdb remain
> In test #2 I do NOT execute the "CreateWorkspace", everything else is
> equal like test #1. Then with Access the terminating problem has
> disappeared. So I thought that the workspace must be the "heart" of the
> problem.
> In test #3 I execute the "CreateWorkspace" and then additionally execute
> the following 2 lines:
> mwspDAO.Close
> Set mwspDAO = Nothing
> (and the rest again equal to test #1). The terminating problem with Access
> again arises like in test #1. I don't grasp that. What is the difference
> between test #2 and test #3? If I close the workspace and set it to
> nothing, what can be the difference to the situation where I never
> instanciate the workspace? Are there "stronger" methods to destroy DAO
> objects, or what can be done here to solve this problem?
>
>
|
|
|
[Quoted Text] > the value "GlobalMultiUse" of the instancing property.
So Access is using the same copy of the dbengine that you
are using.
Access used to have this problem, that multiple references
to the dbengine shut down at the same time, so I am not surprised,
but still, more likely that the problem is your code, not a
feature of dbEngine.
In your code, try creating a new instance of dbengine, like
you would create any new object
set dbe = createobject("dao.dbengine.36")
instead of using the auto-instantiation that happens when you
create workspace or open database.
Explicitly use your dbengine object to open your workspace:
dbe.createworkspace
(david)
"Lorenz Ingold" <l.ingold[ at ]winvs.ch> wrote in message
news:%237ACtCVuHHA.5028[ at ]TK2MSFTNGP02.phx.gbl...
> I do never create the DBEngine object. This is available because I have
set
> a reference to "Microsoft DAO 3.6 Object Library". DBEngine seems to have
> the value "GlobalMultiUse" of the instancing property. The same is with
> terminating: I do nothing about this (no closing or setting to nothing).
>
> How can we use threads in VB6? I thought this is not possible (at least I
> never used it).
>
> We had earlier used an A.exe (a VB6 Standard Exe) to call B.dll, instead
of
> A.mdb calling B.dll. The A.exe closes properly, we never had the
terminating
> problems here. But this is not the comfort we want for the user: The A.exe
> is then used like an external tool which must be called separately. The
user
> wants to work only with A.mdb.
>
> I could perhaps try to call A.exe from A.mdb, then it should be in a
> different process (is this true?). How can then A.mdb see when the process
> of A.exe has finished?
>
> "DAVID" <david[ at ]nospam.nspam> wrote in message
> news:eRaLzlSuHHA.2752[ at ]TK2MSFTNGP06.phx.gbl...
> > You are using DBEngine in C.dll?
> > Show the code that creates the DBEngine object.
> >
> > What code do you have that closes the dbengine object?
> >
> > CreateWorkspace will create threads. You aren't doing this inside a
thread
> > instatiation are you?
> >
> > Can you try creating object B from a different program? Does B close
> > cleanly when Access is not open? when access is open but in a different
> > process?
> >
> > (david)
> >
> >
> >
> > Lorenz Ingold wrote:
> >> Here the whole story: We have a programfile A.mdb (Version: MSAccess
> >> 2003), which instanciates a COM component B.dll, which in turn
> >> instanciates C.dll. In C.dll, we do some database manipulations in an
SQL
> >> server database, therefore we create a workspace like follows:
> >> set mwspDAO = DBEngine.CreateWorkspace("wspData", "", "", dbUseODBC)
> >> Later when A.mdb should terminate (with the command: application.quit),
> >> MSAccess has problems, it does not close. Depending whether the whole
> >> thing is in a full access or a runtime environment, the Access main
> >> window shortly disappears and reappears and then flashes several times
> >> per second, or it comes a message that the program has stopped because
of
> >> a runtime error, but there is never possible to close it.
> >> I did the following test (test #1): After the "CreateWorkspace" I skip
> >> the main actions of C.dll and do only terminating actions. The problems
> >> with A.mdb remain
> >> In test #2 I do NOT execute the "CreateWorkspace", everything else is
> >> equal like test #1. Then with Access the terminating problem has
> >> disappeared. So I thought that the workspace must be the "heart" of the
> >> problem.
> >> In test #3 I execute the "CreateWorkspace" and then additionally
execute
> >> the following 2 lines:
> >> mwspDAO.Close
> >> Set mwspDAO = Nothing
> >> (and the rest again equal to test #1). The terminating problem with
> >> Access again arises like in test #1. I don't grasp that. What is the
> >> difference between test #2 and test #3? If I close the workspace and
set
> >> it to nothing, what can be the difference to the situation where I
never
> >> instanciate the workspace? Are there "stronger" methods to destroy DAO
> >> objects, or what can be done here to solve this problem?
> >>
>
|
|
|