Application Level Close Event

[Ronald Dodge]

Is there a such thing as an application level Close Event so as when the
application is getting closed out, I have have the VBA reset various object
variables so as the "MSACCESS.EXE" process file isn't left open? The only
way I been able to get around this issue is by using form level open and
close events, but I don't like doing this cause of the processing time
dealing with recordsets.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Dirk Goldgar]

In

Is there a such thing as an application level Close Event so as when
the application is getting closed out, I have have the VBA reset
various object variables so as the "MSACCESS.EXE" process file isn't
left open? The only way I been able to get around this issue is by
using form level open and close events, but I don't like doing this
cause of the processing time dealing with recordsets.

There is no such event. The standard workaround, when it is necessary,
is to use the Close or Unload event of a form (possibly hidden) that is
opened at startup and never closed so long as the application is open.

But if the msaccess.exe process is being left running after you have
closed the Access application, it's a sign that something is wrong.
From the sound of it, you have may have global recordset objects that
aren't being closed. Unless you're doing that intentionally, you should
look into your application's logic to see why those objects aren't
closed.

 

[Ronald Dodge]

Yes, I do have global level recordsets as is designed. To get around this
issue, I had modulated the recordsets to have one procedure open them, and
another close though.

However, I had used the Open and Close events of the various forms to open
and close the recordsets, which I don't like that idea cause of the amount
of processing time it could very well take between forms (So unuserfriendly
and wasted use of processing time and resources).

So you saying, if I have a form open up and hidden at the time when the file
is opened, but then when the file is closed, the form will close, which then
the close event of that form will close out the recordsets provided the code
within the event is either setup as such or calling on a procedure to
perform those tasks?

If this is the case, then this will resolve some of my issues. This would
also help in setting up certain other things such as a timer mechanism for
allowing the program to be closed out automatically so as to set idle
limitations as well as for allowing for when maintenance needs to be done on
the DB files, such as the BE files in exclusive mode, if needed.

I'm already thinking of so many uses and aspects with just this one
suggestion.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Dirk Goldgar]

In

So you saying, if I have a form open up and hidden at the time when
the file is opened, but then when the file is closed, the form will
close, which then the close event of that form will close out the
recordsets provided the code within the event is either setup as such
or calling on a procedure to perform those tasks?
Exactly.

I'm already thinking of so many uses and aspects with just this one
suggestion.

Yes, you can make such a form your application-level-control object.

One note regarding your comment about using the form as a timer to
enforce idle-time limitations, etc. This is a well-established process
(you can google for sample code), but you should remember to close the
form or disable its Timer event while editing code. Otherwise you'll
get flaky behavior within the VBA Editor.

 

[Ronald Dodge]

Yep, I know how that is as far as the flaky behavior is concerned. I have
been doing programming work for the last 10 years or so not counting the
prior years of doing formula writing that already blew a lot of people away.
I have picked up various sample codes over the last few years dealing with
Access and I have also created a few modulated codes myself to use within
Access such as my own custom error checking code so as to allow for only
certain times when a user is to be left on a control to make adjustments to
the data in that control. That one took some time to figure out, which many
people on the users said it wasn't possible. I have since then proven that
it's not only possible, but I also have it in full operation to allow for
both stricter data validation while also allowing user friendliness, which
I'm combining my experiences of data entry (worked as a data transcriber at
the IRS as it was nothing but data entry for 9.4 hours of the 10.5 hours
that we were there for those 6 to 7 nights per week, and didn't even get our
first break until after we were there for 3 hours after the shift started),
as a programmer, and also as a person responsible for the data itself. All
of these experiences is what had me on a drive to find a resolution for the
data validation issue that I faced in Access quite some time ago.

BTW, thank you for your assistance on this.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Ronald Dodge]

Just wanted to give a further update on this as it wasn't only the
recordsets being open that caused the process file to remain open, but for
those systems that's on Windows 2000 Pro, MDAC 2.8 must be manually loaded
onto the system as that version isn't on the system unlike it's built into
Windows XP. With the code reference MDAC 2.8 and the system NOT having the
MDAC 2.8 on it, even with a form serving as database level events to close
out the global recordsets, the process file will remain open and you may
even experience the application window itself not really closing out, though
at first looks like will close as it disappears for a brief moment, but then
it comes right back up on the screen depending on your security level in
Access. This happens to those that has administrative rights versus those
that doesn't, the application itself closes, but the process file remains
open.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Dirk Goldgar]

In

Just wanted to give a further update on this as it wasn't only the
recordsets being open that caused the process file to remain open,
but for those systems that's on Windows 2000 Pro, MDAC 2.8 must be
manually loaded onto the system as that version isn't on the system
unlike it's built into Windows XP. With the code reference MDAC 2.8
and the system NOT having the MDAC 2.8 on it, even with a form
serving as database level events to close out the global recordsets,
the process file will remain open and you may even experience the
application window itself not really closing out, though at first
looks like will close as it disappears for a brief moment, but then
it comes right back up on the screen depending on your security level
in Access. This happens to those that has administrative rights
versus those that doesn't, the application itself closes, but the
process file remains open.

Interesting. Thanks for the update. Does your application really
require MDAC 2.8? It's odd that you don't get some other sort of error
if it does, and that version isn't present on the system where it's
running. Does it show up as a broken reference in the References
dialog?

 

[Ronald Dodge]

Yes, it did show up as a missing reference. However, this would only show
up as missing for systems that has Windows 2000 Pro as the OS, not Windows
XP as the OS. By downloading and installing MDAC 2.8, SP1 onto the systems
with W2K Pro, it has resolved the issue.

Two or three years ago, I had worked on various aspects of Access using
unbound forms and such, which if I ever needed support, I knew the first
thing was to make sure I was up to date on the latest versions and updates
as support in at least 95% of the cases (at least with my own personal
experiences) would require the latest updates and versions be in use that
would be available for the major version of the program that I'm working
with, provided that major version is still in support at the time of request
for support.

As I'm going along with this project, I'm finding that I'm bringing many of
the items that I have done before into this project for one reason or
another.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000