Launching Access .mdb file directly vs. launching with VBA

[microb0x]

Is there any difference in the way an Access .mdb file is launched from
directly double-clicking the file through windows explorer versus using
code within another Access file to launch the same file?

Here is my situation:

I have an application that when launched does a check whether or not
its the most current version of the Front End that I have in
production. If the front end is out of date, it closes, and launches
another access .mdb file that serves as an update utitlity. My problem
is when this update utility is launched.

I have code within this update utility to hide the main Access
container window, API courtesy of Dev Ashish, for example:

fSetAccessWindow(SW_HIDE)

I know that there has to be an active form already open to call this
function so I'm opening a hidden form upon open of the Access file,
using the timer to wait 1/2 second then opening my main form and
calling that function.

If I just use windows explorer to launch this update utility directly
it works like a charm. However when I try to launch this utility from
within my other Access file I get an error:

"Cannot hide Access unless a form is on the screen"

I have tried two methods of launching this update utility from within
the other Access file:

Method 1:

Set objAccess = New Access.Application
objAccess.OpenCurrentDatabase "C:\..." ' valid path is there in my code

Method 2:

Application.Followhyperlink "C:\..." ' valid path was used here as
well.

Both methods yield the above error...

Any suggestions or can anyone give any insight into what differences
there are from just double-clicking the file or launching via code?

 

[Geoff]

If the front end is out of date, it closes, and launches

another access .mdb file that serves as an update utitlity.

How are you closing the front end?

What does the update utility do?

Regards
Geoff

 

[Rick Brandt]

Is there any difference in the way an Access .mdb file is launched from
directly double-clicking the file through windows explorer versus using
code within another Access file to launch the same file?

Here is my situation:

I have an application that when launched does a check whether or not
its the most current version of the Front End that I have in
production. If the front end is out of date, it closes, and launches
another access .mdb file that serves as an update utitlity. My problem
is when this update utility is launched.

I have code within this update utility to hide the main Access
container window, API courtesy of Dev Ashish, for example:

fSetAccessWindow(SW_HIDE)

I know that there has to be an active form already open to call this
function so I'm opening a hidden form upon open of the Access file,
using the timer to wait 1/2 second then opening my main form and
calling that function.

If I just use windows explorer to launch this update utility directly
it works like a charm. However when I try to launch this utility from
within my other Access file I get an error:

"Cannot hide Access unless a form is on the screen"[snip]

On the one utility app I have where I use that API I occassionally get the same
thing. The timing is critical for that to work and if you have just closed
another Access app it seems to mess with the timing just enough to cause that
problem.

What I do is launch the VersionChecker app with my applications shortcut
directly. It then decides if the front end of the "real" app is current and
replaces it if not. Then it launches the app and closes itself.

Your method has the advantage of running the updater regardless of how the main
file is opened, but the disadvantage of having to open three files when an
update is required. My way only works if they open the version checker first,
but my custom shortcut is usually required for my app to open anyway so that is
not an issue.

 

[microb0x]

Do you have any suggestion as far as acheiving that crucial timing to
make this work as I want? Is it a matter of delaying that process on
my utility app? I already have a delay but do I need to increase it?

I would really like to keep my method of launching the "real" app first
then launching the update utility if need be.

I noticed you stated that if I just closed another access app it seems
to mess with it. I'm actually creating the new access instance prior
to closing the "real" app, but then immediately calling docmd.quit on
the real app. Here is the code:

'Launch VersionControl Utility then close current app
Set objAccess = New Access.Application
objAccess.OpenCurrentDatabase vPath2
DoCmd.Quit

Would it help if I did a delay prior to calling docmd.quit ?

I'm glad to see someone has experienced a similar issue and has some
knowledge of why this is occuring.. Thanks for your assistance.

 

[Guest]

I have several applications that I have to maintain on numerous machines.

I've got it setup so that my version checker is in the startup list on each
of the machines. Since they have to log out each night, this guarantees that
they have the latest version the next time they boot their machine.
--
Email address is not valid.
Please reply to newsgroup only.

Do you have any suggestion as far as acheiving that crucial timing to
make this work as I want? Is it a matter of delaying that process on
my utility app? I already have a delay but do I need to increase it?

I would really like to keep my method of launching the "real" app first
then launching the update utility if need be.

I noticed you stated that if I just closed another access app it seems
to mess with it. I'm actually creating the new access instance prior
to closing the "real" app, but then immediately calling docmd.quit on
the real app. Here is the code:

'Launch VersionControl Utility then close current app
Set objAccess = New Access.Application
objAccess.OpenCurrentDatabase vPath2
DoCmd.Quit

Would it help if I did a delay prior to calling docmd.quit ?

I'm glad to see someone has experienced a similar issue and has some
knowledge of why this is occuring.. Thanks for your assistance.

 

[microb0x]

I have found a solution to this problem. I would like to share this
for the benefit of this group..

There was no need for me to add any delays in any of the steps to get
this to work the way I liked. It seems that making my new instance of
access visible prior to opening the database makes it perform the
proper procedures with my initial form.

My original code that wasnt working:

'Launch VersionControl Utility then close current app
Set objAccess = New Access.Application
objAccess.OpenCurrentDatabase vPath2
DoCmd.Quit


Now this is the code that is working:

'Launch VersionControl Utility then close current app
Set objAccess = New Access.Application
objAccess.Visible = True
objAccess.OpenCurrentDatabase vPath2
DoCmd.Quit

The addition of this line of code: objAccess.Visible = True
is what made it work.

So it appears that access acts differently when opening a database
depending on wether or not that instance of access is visible at the
time.