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 ?

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.
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.

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 (AT) msn (DOT) com

On Jul 30, 2:45*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:
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 ?

On 31 Jul., 00:24, Roger wrote:

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

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

On Jul 31, 11:16*am, Marco Pagliero <mart... (AT) web (DOT) de> wrote:
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

"Roger" <lesperancer (AT) natpro (DOT) com> wrote


Unfortanatly, it don't work that way.

Remember, you are using object automation to create a running instances of
<insert ANY com program here>

So, you mean word is also going to start in runtime mode? or perhaps
Outlook, or maybe you are launching an instance of AutoCad in runtime mode?
(oh, wiat,t they don't have a runtime mode!).

You are simply in code creating an instance of a running object which in
your case happens to be access. You can use windows scripting, or word, or
excel to also create that running instance of access using the createojbect
command.

Access itself has absolute ZERO knowledge about the program that is
creating the instance of Access.

Yes, the above is an correct assumption.
I believe that GetObject will return the most recent instance by default,
but I can't say I tested this concept in production code. You have have to
try some things out.

Perhaps you can add some code to get the window name or some such.

Since access does not support automation with a file name specifed, then
this quite much removes use of createobject().

This restriction exists for any automation client attempting to create an
running instance of access in runtime.

I unfortunately don't have any better suggestion then trying something based
on shell().

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

On Jul 30, 2:45*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:
I created this function
using the full version, even though the shell command opened db3, the
getObject() call creates a second copy

which means, when using the runtime, I have the same problem (can't
create activex component)

I wonder why the full version isn't detecting that a copy of db3 is
already running ?

Public Function t3()
Dim obj As Access.Application
Dim strCmd As String
Dim strPath As String

On Error GoTo ferr
strPath = "\\dev01\access\development\db3.mdb"
strCmd = "C:\Program Files (x86)\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
strCmd = "C:\Program Files\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
MsgBox "Can't find access2007"
Exit Function
End If
End If

strCmd = strCmd & "\msaccess.exe"
strCmd = strCmd & " " & Chr(34) & strPath & Chr(34)
Shell strCmd
MsgBox 1
Set obj = GetObject(strPath, "Access.Application")
MsgBox 2
With obj
.Visible = True
.RefreshTitleBar
MsgBox "db3"
End With
fexit:
Exit Function
ferr:
MsgBox "err " & Err.Description
End Function

On Aug 1, 6:42*am, Roger <lesperan... (AT) natpro (DOT) com> wrote:
I got it working using
Set obj = GetObject(, "Access.Application")

but it turns out that some of the things I wanted to do
with the object (visible / run) aren't working
With obj
.Visible = True
.RefreshTitleBar
.RunCommand acCmdAppMaximize
.Run "editHandover", "H", 999
End With

so I'm passing the function to "run" as
part of the command line, and I'm using vbMaximizedFocus
to get what I need, so the final version is

Public Function t3()
Dim strCmd As String
Dim strPath As String

On Error GoTo ferr
strPath = "\\dev01\access\development\db3.mdb"
strCmd = "C:\Program Files (x86)\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
strCmd = "C:\Program Files\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
MsgBox "Can't find access2007"
Exit Function
End If
End If

strCmd = strCmd & "\msaccess.exe"
strCmd = strCmd & " " & Chr(34) & strPath & Chr(34)
strCmd = strCmd & " /cmd editHandover|H|99"
Shell strCmd, vbMaximizedFocus

fexit:
Exit Function
ferr:
MsgBox "err " & Err.Description
End Function

Albert D. Kallal wrote:
I'm curious about that statement. Does that also include Word, Outlook,
and Excel?

"Salad" <salad (AT) oilandvinegar (DOT) com> wrote

Well, READ carefully again what I further clarify in those posts.

In fact as I stated, access doesn't know or care what language is being used
here, from visual basic scripting, visual basic .net, FoxPro or word, or
even another copy of access running, the language or what application here
is not really an access particular issue in terms of automation.

To state again: The access runtime shuts down if you don't supply a file
name when you start it up. This behaviors been this way for very long time.
If you think about this, it kind makes sense that if you click on the access
runtime icon, because there is no user interface and there is no ability to
open up a file, it would be rather quite silly to leave a copy of the
application running in memory. If you clicked on that access icon, you would
be launching multiple copies of access each time you click, and because the
runtime has no user interface, you would have no way of shutting down the
application.

So the default behavior of the runtime is that, when you launch it or create
an automated instance of the runtime, since there's no file name supplied,
the application then simply shuts down.

In effect it means that when you launch the runtime, you must supply in
access file or database to open when you do so, and then the copy of access
will remain running.

The core problem or issue here is of course, is that when you automate an
instance of access (createObject), it's not possible to supply the file name
to be opened. Therefore logical reasoning and intellectual deduction makes
one realize that this behavior means you can't use automation to create a
running instance of access in this case.

So this has absolutely nothing to do with behavior of word or outlook or
excel or any other application that you attempt to launch. (they will all
launch and run just fine even when you use the access runtime).

If you're willing to think through all of the results of this behavior
yourself, I only need to tell you one thing:

The access runtime shuts down when it's launched without a file name
supplied for it to work with.

Everything else that follows is a result of the above information can then
be intellectually realized and thought out by you.
Of course the second piece of the puzzle is that when you automate access,
you can't supply a file name, therefore logic dictates you can't use
automation this case can you?

So the limitation we are witnessing here is the results of a particular
behavior of the access runtime, and that behavior is simply that acess shuts
down when no file name is supplied.

Albert K.