469,626 Members | 1,812 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,626 developers. It's quick & easy.

docmd.quit vs. Application.Quit

Just noticed something interesting in the above. If you have your program
file set to "Compact on Close" in access 2007 (which is desirable when you
have a larger program that frequently needs compacting), if you use the
following code on an "Exit Application" type button, the compacting on close
won't fire:

Application.Quit acQuitSaveNone

however, if you use:

Docmd.Quit

Then the compacting on close does fire.

Has anyone else seen this? Any dangers with docmd.quit, or is
application.quit just a preferred method?

Many Thanks,

Oct 29 '08 #1
9 20398
"Andy" <PC*****@PCESoft.invalidwrote in message
news:Ma*****************@nlpi065.nbdc.sbc.com...
Just noticed something interesting in the above. If you have your program
file set to "Compact on Close" in access 2007 (which is desirable when you
have a larger program that frequently needs compacting), if you use the
following code on an "Exit Application" type button, the compacting on
close won't fire:

Application.Quit acQuitSaveNone

however, if you use:

Docmd.Quit

Then the compacting on close does fire.

Has anyone else seen this? Any dangers with docmd.quit, or is
application.quit just a preferred method?
For me, compact on close is not a required option because I have my apps set
up such that a new, pristine front end file is delivered to the user's PC
with every new session. As far as I can tell, compact on close is only ever
any use when you have a single file single user application. There are
issues with the DoCmd.Quit method although, off the top of my head I can't
remember what they are. What I do remember is recently going through all of
my apps and replacing every instance with Application.Quit. But if your app
is of the single file single user nature (ie only you use it) then I
wouldn't lose too much sleep about using DoCmd.Quit.

Keith.
www.keithwilby.co.uk

Oct 30 '08 #2
Thanks for the reply, Keith.

It's a front end / back end runtime app. People have posted before against
using the compact on close, but in my testing, you're really talking about
only compacting the front end on close, it won't do anything to the back
end, so I'm leaning towards 'compacting on close' being a great thing (see
my new post from a few minutes ago)...

Take care,

"Keith Wilby" <he**@there.comwrote in message
news:49********@glkas0286.greenlnk.net...
"Andy" <PC*****@PCESoft.invalidwrote in message
news:Ma*****************@nlpi065.nbdc.sbc.com...
>Just noticed something interesting in the above. If you have your program
file set to "Compact on Close" in access 2007 (which is desirable when
you have a larger program that frequently needs compacting), if you use
the following code on an "Exit Application" type button, the compacting
on close won't fire:

Application.Quit acQuitSaveNone

however, if you use:

Docmd.Quit

Then the compacting on close does fire.

Has anyone else seen this? Any dangers with docmd.quit, or is
application.quit just a preferred method?

For me, compact on close is not a required option because I have my apps
set up such that a new, pristine front end file is delivered to the user's
PC with every new session. As far as I can tell, compact on close is only
ever any use when you have a single file single user application. There
are issues with the DoCmd.Quit method although, off the top of my head I
can't remember what they are. What I do remember is recently going
through all of my apps and replacing every instance with Application.Quit.
But if your app is of the single file single user nature (ie only you use
it) then I wouldn't lose too much sleep about using DoCmd.Quit.

Keith.
www.keithwilby.co.uk
Oct 30 '08 #3
Keith Wilby wrote:
"Andy" <PC*****@PCESoft.invalidwrote in message
news:Ma*****************@nlpi065.nbdc.sbc.com...
>Just noticed something interesting in the above. If you have your
program file set to "Compact on Close" in access 2007 (which is
desirable when you have a larger program that frequently needs
compacting), if you use the following code on an "Exit Application"
type button, the compacting on close won't fire:

Application.Quit acQuitSaveNone

however, if you use:

Docmd.Quit

Then the compacting on close does fire.

Has anyone else seen this? Any dangers with docmd.quit, or is
application.quit just a preferred method?

For me, compact on close is not a required option because I have my apps
set up such that a new, pristine front end file is delivered to the
user's PC with every new session.
What happens when a user attempts to open 2 sessions of the application?

As far as I can tell, compact on
close is only ever any use when you have a single file single user
application. There are issues with the DoCmd.Quit method although, off
the top of my head I can't remember what they are. What I do remember
is recently going through all of my apps and replacing every instance
with Application.Quit. But if your app is of the single file single
user nature (ie only you use it) then I wouldn't lose too much sleep
about using DoCmd.Quit.
If one compacts on close, isn't the compact on the FE? Again, I'd think
this could be a problem if you had 2 or more sessions open.
>
Keith.
www.keithwilby.co.uk
Oct 30 '08 #4
"Salad" <oi*@vinegar.comwrote in message
news:YM******************************@earthlink.co m...
Keith Wilby wrote:
>>
For me, compact on close is not a required option because I have my apps
set up such that a new, pristine front end file is delivered to the
user's PC with every new session.

What happens when a user attempts to open 2 sessions of the application?
A good question but it's a scenario I've never encountered. I suspect that
it will be the same as 2 users sharing a FE file on a server. In the 10 or
so years I've been using that setup I've never had any problems with it.
Would you recommend a different approach or even having code to mitigate for
that possibility?

Keith.

Oct 30 '08 #5
Using full access, you can open 2 instances of the same program (which I've
done by mistake many times). But using the runtime, you can't open a second
instance of the same mde/accde file.
"Keith Wilby" <he**@there.comwrote in message
news:49**********@glkas0286.greenlnk.net...
"Salad" <oi*@vinegar.comwrote in message
news:YM******************************@earthlink.co m...
>Keith Wilby wrote:
>>>
For me, compact on close is not a required option because I have my apps
set up such that a new, pristine front end file is delivered to the
user's PC with every new session.

What happens when a user attempts to open 2 sessions of the application?

A good question but it's a scenario I've never encountered. I suspect
that it will be the same as 2 users sharing a FE file on a server. In the
10 or so years I've been using that setup I've never had any problems with
it. Would you recommend a different approach or even having code to
mitigate for that possibility?

Keith.
Oct 30 '08 #6
Keith Wilby wrote:
"Salad" <oi*@vinegar.comwrote in message
news:YM******************************@earthlink.co m...
>Keith Wilby wrote:
>>>
For me, compact on close is not a required option because I have my
apps set up such that a new, pristine front end file is delivered to
the user's PC with every new session.


What happens when a user attempts to open 2 sessions of the application?

A good question but it's a scenario I've never encountered. I suspect
that it will be the same as 2 users sharing a FE file on a server. In
the 10 or so years I've been using that setup I've never had any
problems with it. Would you recommend a different approach or even
having code to mitigate for that possibility?
I probably would use some code to enumerate the class/caption of open
windows http://www.mvps.org/access/api/api0013.htm. If one exists I
know a session of the app is open and would not copy over another copy
of the app.
Keith.
Oct 30 '08 #7
Andy wrote:
Using full access, you can open 2 instances of the same program (which
I've done by mistake many times). But using the runtime, you can't open
a second instance of the same mde/accde file.
My users of A2003 don't have that problem. They can open up multiple
instances of the app with an MDE using the runtime. Maybe it's a 2007
thing.

>

"Keith Wilby" <he**@there.comwrote in message
news:49**********@glkas0286.greenlnk.net...
>"Salad" <oi*@vinegar.comwrote in message
news:YM******************************@earthlink.c om...
>>Keith Wilby wrote:
For me, compact on close is not a required option because I have my
apps set up such that a new, pristine front end file is delivered to
the user's PC with every new session.
What happens when a user attempts to open 2 sessions of the application?

A good question but it's a scenario I've never encountered. I suspect
that it will be the same as 2 users sharing a FE file on a server. In
the 10 or so years I've been using that setup I've never had any
problems with it. Would you recommend a different approach or even
having code to mitigate for that possibility?

Keith.

Oct 30 '08 #8
I use the sagekey script, so maybe it's opening as exclusive using their
shortcuts, etc.
"Salad" <oi*@vinegar.comwrote in message
news:WL******************************@earthlink.co m...
Andy wrote:
>Using full access, you can open 2 instances of the same program (which
I've done by mistake many times). But using the runtime, you can't open a
second instance of the same mde/accde file.

My users of A2003 don't have that problem. They can open up multiple
instances of the app with an MDE using the runtime. Maybe it's a 2007
thing.

>>

"Keith Wilby" <he**@there.comwrote in message
news:49**********@glkas0286.greenlnk.net...
>>"Salad" <oi*@vinegar.comwrote in message
news:YM******************************@earthlink. com...

Keith Wilby wrote:

>
For me, compact on close is not a required option because I have my
apps set up such that a new, pristine front end file is delivered to
the user's PC with every new session.
What happens when a user attempts to open 2 sessions of the
application?
A good question but it's a scenario I've never encountered. I suspect
that it will be the same as 2 users sharing a FE file on a server. In
the 10 or so years I've been using that setup I've never had any
problems with it. Would you recommend a different approach or even
having code to mitigate for that possibility?

Keith.
Oct 30 '08 #9
"Salad" <oi*@vinegar.comwrote in message
news:p8******************************@earthlink.co m...
Keith Wilby wrote:
>"Salad" <oi*@vinegar.comwrote in message
news:YM******************************@earthlink.c om...
>>Keith Wilby wrote:
For me, compact on close is not a required option because I have my
apps set up such that a new, pristine front end file is delivered to
the user's PC with every new session.
What happens when a user attempts to open 2 sessions of the application?

A good question but it's a scenario I've never encountered. I suspect
that it will be the same as 2 users sharing a FE file on a server. In
the 10 or so years I've been using that setup I've never had any problems
with it. Would you recommend a different approach or even having code to
mitigate for that possibility?
I probably would use some code to enumerate the class/caption of open
windows http://www.mvps.org/access/api/api0013.htm. If one exists I know
a session of the app is open and would not copy over another copy of the
app.
Thanks Salad.

Oct 31 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Lauren Quantrell | last post: by
reply views Thread by Robert Langen | last post: by
6 posts views Thread by Max | last post: by
reply views Thread by Alan T | last post: by
reply views Thread by Alan T | last post: by
2 posts views Thread by Alan T | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.