access2007 runtime - opening another mdb
in [Help]
|
From: Roger on 30 Jul 2010 08:01 in access2007, I'm trying to open a second MDB using this code that works in access97 Dim obj As Access.Application On Error GoTo fErr Set obj = New Access.Application With obj .Visible = True .RefreshTitleBar .OpenCurrentDatabase "another.mdb" end with it works fine on my development system, even when I use the access2007 /runtime switch but on another system, that has just the runtime installed, the statement Set obj = New Access.Application gives me this error activex component can't create object both systems have 'trusted locations' setup so can I / should I be able to do this with the access2007 runtime ?
From: Albert D. Kallal on 30 Jul 2010 16:45 Unfortunately the runtime environment does not support automation or you creating a new instance of access. In fact to be a little bit more specific here, is what happens is if you launch the access runtime without any file name supplied, then it's simply shuts down. So in your code when you create the access application, it does get created, but then since no file name was supplied when it was opened, then it instantly shuts down. (and in fact when you use automation code, you actually don't have the ability to supply that file name when you create the instance of access) What this means is in a runtime environment, you'll have to use the shell command and shell out with a command line prompt to launch another instance of access, I believe you can then still use GetObject(,"Access.Application") to get at that running instance in your current code. > > it works fine on my development system, even when I use the > access2007 /runtime switch Right, you are starting the current application with the runtime switch, but the creation of the new access application in your code is NOT using the runtime switch. > > so can I / should I be able to do this with the access2007 runtime ? Actually you can't use that code, but as mentioned you should be able to cobble together something that uses the shell() command. Albert D. Kallal (Access MVP) Edmonton, Alberta Canada Pleaseno_Spam_kallal(a)msn.com
From: Roger on 30 Jul 2010 18:24 On Jul 30, 2:45 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...(a)msn.com> wrote: > Unfortunately the runtime environment does not support automation or you > creating a new instance of access. > > In fact to be a little bit more specific here, is what happens is if you > launch the access runtime without any file name supplied, then it's simply > shuts down. > > So in your code when you create the access application, it does get created, > but then since no file name was supplied when it was opened, then it > instantly shuts down. (and in fact when you use automation code, you > actually don't have the ability to supply that file name when you create the > instance of access) > > What this means is in a runtime environment, you'll have to use the shell > command and shell out with a command line prompt to launch another instance > of access, I believe you can then still use GetObject(,"Access.Application") > to get at that running instance in your current code. > > > > > it works fine on my development system, even when I use the > > access2007 /runtime switch > > Right, you are starting the current application with the runtime switch, but > the creation of the new access application in your code is NOT using the > runtime switch. > > > > > so can I / should I be able to do this with the access2007 runtime ? > > Actually you can't use that code, but as mentioned you should be able to > cobble together something that uses the shell() command. > > Albert D. Kallal (Access MVP) > Edmonton, Alberta Canada > Pleaseno_Spam_kal...(a)msn.com you state "Right, you are starting the current application with the runtime switch, but the creation of the new access application in your code is NOT using the runtime switch. " if I start an MDB with the runtime switch, it's because I want to test in runtime mode all the time, not just some of the time so you may be correct, but spawning a new access object from within a runtime environment should behave the same as as spawing it with the actual runtime and if I shell out a second copy of access, how can I be sure that GetObject(,"Access.Application") will use the correct copy, I could have a couple of running copies of access ?
From: Marco Pagliero on 31 Jul 2010 13:16 On 31 Jul., 00:24, Roger wrote: > if I start an MDB with the runtime switch, it's because I want to test > in runtime mode all the time, not just some of the time > so you may be correct, but spawning a new access object from within a > runtime environment should behave the same as > as spawing it with the actual runtime Yes, but as the runtime per definition cannot remain open without a database, this would mean that the IDE must immediatly close when started without a database. But the new instance of access doesn't know that your old instance is running in runtime mode, so they would have had to build in something to imitate this behavior. Probably they didn't think about this point in the first place > and if I shell out a second copy of access, how can I be sure that > GetObject(,"Access.Application") will use the correct copy, I could > have a couple of running copies of access ? There are two more alternatives to "new" (but I don't have the runtime to test them). The first: # Dim objAcc As Access.Application # Set objAcc = CreateObject("Access.Application") # objAcc.OpenCurrentDatabase "C:\YourPath\YourDB.mdb" # ..... # objAcc.Quit # Set objAcc = Nothing I imagine that this version will behave exactly the same way as yours, but I'm just curious. The second: # Dim appACC As Object # Set appACC = GetObject("c:\tar\Mytest.mdb") This one will open or activate only Mytest.mdb, even if there are several other instances of Access open. But yes, it will activate an instance of Mytest.mdb at random if several Mytest.mdb are open. Regards Marco P
From: Roger on 31 Jul 2010 14:43
On Jul 31, 11:16 am, Marco Pagliero <mart...(a)web.de> wrote: > On 31 Jul., 00:24, Roger wrote: > > > if I start an MDB with the runtime switch, it's because I want to test > > in runtime mode all the time, not just some of the time > > so you may be correct, but spawning a new access object from within a > > runtime environment should behave the same as > > as spawing it with the actual runtime > > Yes, but as the runtime per definition cannot remain open without a > database, this would mean that the IDE must immediatly close when > started without a database. But the new instance of access doesn't > know that your old instance is running in runtime mode, so they would > have had to build in something to imitate this behavior. Probably they > didn't think about this point in the first place > > > and if I shell out a second copy of access, how can I be sure that > > GetObject(,"Access.Application") will use the correct copy, I could > > have a couple of running copies of access ? > > There are two more alternatives to "new" (but I don't have the runtime > to test them). > > The first: > # Dim objAcc As Access.Application > # Set objAcc = CreateObject("Access.Application") > # objAcc.OpenCurrentDatabase "C:\YourPath\YourDB.mdb" > # ..... > # objAcc.Quit > # Set objAcc = Nothing > > I imagine that this version will behave exactly the same way as yours, > but I'm just curious. > The second: > > # Dim appACC As Object > # Set appACC = GetObject("c:\tar\Mytest.mdb") > > This one will open or activate only Mytest.mdb, even if there are > several other instances of Access open. But yes, it will activate an > instance of Mytest.mdb at random if several Mytest.mdb are open. > > Regards > Marco P the first method gave me the same error the second method gave me this error file name or class name not found during automation operation note. the file name is \\dev01\access\development\db3.mdb |