 | |
Open a database from a database
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Open a database from a database -
04-12-2011
, 03:37 PM
#2
| |||
| |||
|
#3
| |||
| |||
|
|
I want to be able to open and run an Access database from within an already running one. The OpenDatabase command simply opens it but does not run the startup routine. Interestingly opening from Windows Explorer has a different meaning in that it opens and runs! What command enables me to open another database and get it to run its AutoExec macro, from code? Jim |
#4
| |||
| |||
|
#5
| |||
| |||
|
|
I want to be able to open and run an Access database from within an already running one. The OpenDatabase command simply opens it but does not run the startup routine. Interestingly opening from Windows Explorer has a different meaning in that it opens and runs! What command enables me to open another database and get it to run its AutoExec macro, from code? Jim |
RunCode, OpenForm and Maximize commands.
You can also use Tools > Startup > Display Form/Page:
The above is used in Access 2003.
#6
| |||
| |||
|
|
I want to be able to open and run an Access database from within an already running one. The OpenDatabase command simply opens it but does not run the startup routine. Interestingly opening from Windows Explorer has a different meaning in that it opens and runs! What command enables me to open another database and get it to run its AutoExec macro, from code? |
You can use Shell(), but that launches an independent instance of
Access and you don't have much control over it (though if you use
the function version of Shell() you can get the process ID and then
kill it if you need to). The advantage there is that you can close
the launching application without affecting the one you launched
from it.
Alternatively, you could use automation for full control, but that
makes the second instance dependent on the first. That may be an
advantage or a disadvantage.
Another option is Michael Kaplan's SOON utility:
http://trigeminal.com/lang/1033/utility.asp?ItemID=8#8
I've never used it, but it could be what you need.
Last of all, you might consider whether you need a new instance or
not. If all your trying to do is run some queries or output some
reports that are done in the startup routine of the app, it would
make more sense to move that functionality to code that is called
from the startup routine, but could also then be called without
necessarily needing to open the app in a new instance of Access. But
whether that is possible or not will depend on what tasks are being
performed.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#7
| |||
| |||
|
|
Jim Devenish <internet.shopp... (AT) foobox (DOT) com> wrote innews:0b4510ac-d415-4c2c-b200-7546aae178a4 (AT) gu8g2000vbb (DOT) googlegroups.co m: I want to be able to open and run an Access database from within an already running one. *The OpenDatabase command simply opens it but does not run the startup routine. *Interestingly opening from Windows Explorer has a different meaning in that it opens and runs! What command enables me to open another database and get it to run its AutoExec macro, from code? It all depends on what you want to do. You can use Shell(), but that launches an independent instance of Access and you don't have much control over it (though if you use the function version of Shell() you can get the process ID and then kill it if you need to). The advantage there is that you can close the launching application without affecting the one you launched from it. Alternatively, you could use automation for full control, but that makes the second instance dependent on the first. That may be an advantage or a disadvantage. Another option is Michael Kaplan's SOON utility: *http://trigeminal.com/lang/1033/utility.asp?ItemID=8#8 I've never used it, but it could be what you need. Last of all, you might consider whether you need a new instance or not. If all your trying to do is run some queries or output some reports that are done in the startup routine of the app, it would make more sense to move that functionality to code that is called from the startup routine, but could also then be called without necessarily needing to open the app in a new instance of Access. But whether that is possible or not will depend on what tasks are being performed. -- David W. Fenton * * * * * * * * *http://www.dfenton.com/ contact via website only * *http://www.dfenton.com/DFA/ |
the situation I have: "Have you ever wanted to close a database, then
maybe compact it, and maybe open it back up?
I want to compact and repair my database and reopen it. To do this I
want to pass its pathname to a table in a second database; close the
first and open the second; from here compact and repair the first and
then reopen it.
This need has arisen in a surprising way. I have just moved a number
of applications from A2000 to A2010 and find that in each of them when
I now relink the front end to a new backend, the database needs
compacting or else errors occur. I can't find an explanation about
why what worked previously is now causing a problem, so I am trying
to get round it by automating the compaction.
Jim
#8
| |||
| |||
|
|
This need has arisen in a surprising way. I have just moved a number of applications from A2000 to A2010 and find that in each of them when I now relink the front end to a new backend, the database needs compacting or else errors occur. I can't find an explanation about why what worked previously is now causing a problem, so I am trying to get round it by automating the compaction. |
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.