Unhandled errors; public vars/classes lose scope??

[robert.waters]

Why do my public variables (including class instances) disappear when
my app experiences an unhandled error?

My custom class module's class_terminate event doesn't even fire, the
instance just goes out of scope/gets garbage collected/disappears into
thin air.

Does anyone know why Access behaves in this manner, or more
importantly how to change that behavior?

FYI I am using an AutoExec macro to call a public function (in a
module) that creates an instance of a custom class (to keep track of
session data) thusly:

Public Session As clsSession

Public Function SessionInit()

Set Session = New HDSession

End Sub

[Rick Brandt]

robert.waters wrote:

Why do my public variables (including class instances) disappear when
my app experiences an unhandled error?

My custom class module's class_terminate event doesn't even fire, the
instance just goes out of scope/gets garbage collected/disappears into
thin air.

Does anyone know why Access behaves in this manner, or more
importantly how to change that behavior?

FYI I am using an AutoExec macro to call a public function (in a
module) that creates an instance of a custom class (to keep track of
session data) thusly:

Public Session As clsSession

Public Function SessionInit()

Set Session = New HDSession

End Sub

It's always been that way. MDE's don't do this however.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[robert.waters]

On Apr 14, 1:09 pm, "Rick Brandt" <[e-mail]:

robert.waters wrote:

Why do my public variables (including class instances) disappear when
my app experiences an unhandled error?

My custom class module's class_terminate event doesn't even fire, the
instance just goes out of scope/gets garbage collected/disappears into
thin air.

Does anyone know why Access behaves in this manner, or more
importantly how to change that behavior?

FYI I am using an AutoExec macro to call a public function (in a
module) that creates an instance of a custom class (to keep track of
session data) thusly:

Public Session As clsSession

Public Function SessionInit()

Set Session = New HDSession

End Sub

It's always been that way. MDE's don't do this however.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Thank you Rick.
So, the only viable option for saving session data is with a hidden
form? Not a tasty hack...

[Rick Brandt]

robert.waters wrote:

On Apr 14, 1:09 pm, "Rick Brandt" <[e-mail]:

robert.waters wrote:

Why do my public variables (including class instances) disappear
when my app experiences an unhandled error?

My custom class module's class_terminate event doesn't even fire,
the instance just goes out of scope/gets garbage
collected/disappears into thin air.

Does anyone know why Access behaves in this manner, or more
importantly how to change that behavior?

FYI I am using an AutoExec macro to call a public function (in a
module) that creates an instance of a custom class (to keep track
of session data) thusly:

Public Session As clsSession

Public Function SessionInit()

Set Session = New HDSession

End Sub

It's always been that way. MDE's don't do this however.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Thank you Rick.
So, the only viable option for saving session data is with a hidden
form? Not a tasty hack...

Or use an MDE
Or use classes (don't think they have this issue)
Or handle all errors

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[robert.waters]

On Apr 14, 2:05 pm, "Rick Brandt" <[e-mail]:

robert.waters wrote:

On Apr 14, 1:09 pm, "Rick Brandt" <[e-mail]:

robert.waters wrote:
Why do my public variables (including class instances) disappear
when my app experiences an unhandled error?

My custom class module's class_terminate event doesn't even fire,
the instance just goes out of scope/gets garbage
collected/disappears into thin air.

Does anyone know why Access behaves in this manner, or more
importantly how to change that behavior?

FYI I am using an AutoExec macro to call a public function (in a
module) that creates an instance of a custom class (to keep track
of session data) thusly:

Public Session As clsSession

Public Function SessionInit()

Set Session = New HDSession

End Sub

It's always been that way. MDE's don't do this however.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Thank you Rick.
So, the only viable option for saving session data is with a hidden
form? Not a tasty hack...

Or use an MDE
Or use classes (don't think they have this issue)
Or handle all errors

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

FYI a class module exhibited that behavior as well.
Thanks for your help.

[Albert D. Kallal]

"robert.waters" <ro***********@gmail.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.com...

Why do my public variables (including class instances) disappear when
my app experiences an unhandled error?

VB always been that way.

the simple solution is to either have error handling in your code. And, as
others mentioned, if serious about using ms-access, then you need to deploy
using a mde.

However, if you deploy a mde then you can't make changes to the resulting
designs, and thus, it follows that you split your database.

So, really, the issue here is that you need to put on a "developers" cap,
and
split your database. Splitting will allow you to deploy a mde, and then
continue
working on the next "great" release of your software (the mdb part).

I explain this concept and process here:

http://www.members.shaw.ca/AlbertKal...plit/index.htm

Once you "grasp" the development process in ms-access, then your find the
re-set
of varialbes problem goes away....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[robert.waters]

On Apr 14, 4:21 pm, "Albert D. Kallal" <[e-mail]>
wrote:

"robert.waters" <[e-mail] in message

news:11**********************@q75g2000hsh.googlegr oups.com...

Why do my public variables (including class instances) disappear when
my app experiences an unhandled error?

VB always been that way.

the simple solution is to either have error handling in your code. And, as
others mentioned, if serious about using ms-access, then you need to deploy
using a mde.

However, if you deploy a mde then you can't make changes to the resulting
designs, and thus, it follows that you split your database.

So, really, the issue here is that you need to put on a "developers" cap,
and
split your database. Splitting will allow you to deploy a mde, and then
continue
working on the next "great" release of your software (the mdb part).

I explain this concept and process here:

http://www.members.shaw.ca/AlbertKal...plit/index.htm

Once you "grasp" the development process in ms-access, then your find the
re-set
of varialbes problem goes away....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
[e-mail]

Thanks Albert; I have a split database (SQL server + .mdb). My error
handling is fine, thanks; this issue arose while trying to .Raise an
error in test.
Please forgive me for being surprised when my objects disappeared
without so much as a whisper from their deconstructor; surely it must
be that Visual Basic is beyond my "grasp".
As for my developer's cap, well it's old, worn, and tattered but it
fits me perfectly.
I do appreciate your comments (though unnecessarily condescending).

[John Mishefske]

robert.waters wrote:

>
FYI a class module exhibited that behavior as well.
Thanks for your help.

Perhaps the instance of the class was saved in a reference variable in a module and that
is why the class did this.

Why not use tables to store your values?

Error handling should prevent this issue. I've used code to re-instantiate the class if I
find I don't have a reference to it but might not be a viable answer for your project.

I've used the hidden form method as well; a side benefit of immediately opening a hidden
form is that it is guaranteed to be the last form closed (LIFO) and so you can put code in
the Unload event to run whenever the application is closed and doing any necessary cleanup.

--
---------------
John Mishefske, Microsoft Access MVP