victoresq
asked on
retain in memory issues with vb6 dll
So here it goes,
the VB6 dll is being accessed by java objects via a wrapper (but I do not think this is an issue, but I add it in for completeness).
I have a dll that was constructed in vb6 call hello.dll (for instance).
I have been able to run this dll from various objects of various classes for almost a month straight, then all of a sudden no object could access the dll. Although the objects were not faulting they were experiencing issues in accessing the data.
Upon further investigation the "retain in memory" option was not chosen, and following some advise that I found on the net, set this variable, recompiled, and re-issued the dll.
Now I was able to recompile the java code and attempt to re-instantiate the objects (put them online). To my supprise 2 out of the three class types liked the new dll, and the objects of those types came online. The third class type had faulted objects. hmmm...they all make the same call to the same dll?
the error I was recieving indicated and accessing issue.
So in my infinite wisdom, I recompiled the dll without the "retain in memory" option checked and viola everybody loves the dll. Except of course I do not trust the longevity of the interaction between the dll and the various objects.
So I retested and checked the "retain in memory" option and once again experienced the same faulting situation with the same objects.
I thought it was perhaps first come first serve, but I dispelled this theory by first trying to bring online the objects of the troublesome class. With the same result.
so what I did to bandade the issue was construct a separate dll (with the "retain in memory" option checked) using the same code under a different name. This time the objects of the second class type (now pointing to the new dll) loved the dll and came online without faulting???
Other than having two dll's and having to compile two separate dll's each time I make an upgrade, the system seems to perform as expected.
It just bothers me that this situation exists.
any suggestions?
whodaman
the VB6 dll is being accessed by java objects via a wrapper (but I do not think this is an issue, but I add it in for completeness).
I have a dll that was constructed in vb6 call hello.dll (for instance).
I have been able to run this dll from various objects of various classes for almost a month straight, then all of a sudden no object could access the dll. Although the objects were not faulting they were experiencing issues in accessing the data.
Upon further investigation the "retain in memory" option was not chosen, and following some advise that I found on the net, set this variable, recompiled, and re-issued the dll.
Now I was able to recompile the java code and attempt to re-instantiate the objects (put them online). To my supprise 2 out of the three class types liked the new dll, and the objects of those types came online. The third class type had faulted objects. hmmm...they all make the same call to the same dll?
the error I was recieving indicated and accessing issue.
So in my infinite wisdom, I recompiled the dll without the "retain in memory" option checked and viola everybody loves the dll. Except of course I do not trust the longevity of the interaction between the dll and the various objects.
So I retested and checked the "retain in memory" option and once again experienced the same faulting situation with the same objects.
I thought it was perhaps first come first serve, but I dispelled this theory by first trying to bring online the objects of the troublesome class. With the same result.
so what I did to bandade the issue was construct a separate dll (with the "retain in memory" option checked) using the same code under a different name. This time the objects of the second class type (now pointing to the new dll) loved the dll and came online without faulting???
Other than having two dll's and having to compile two separate dll's each time I make an upgrade, the system seems to perform as expected.
It just bothers me that this situation exists.
any suggestions?
whodaman
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.