access2007 runtime - opening another mdb

#11

On Aug 1, 12:18*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:

Quote:

"Salad" <sa... (AT) oilandvinegar (DOT) com> wrote in message

news:zfCdnU9tHNNIHsjRnZ2dnUVZ_u-dnZ2d (AT) earthlink (DOT) com...

Albert D. Kallal wrote:
Unfortunately the runtime environment does not support automation or you
creating a new instance of access.

I'm curious about that statement. *Does that also include Word, Outlook,
and Excel?

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.

but my point is, the access runtime knows (should know the difference)
between launched from explorer vs launched from automation
and as such should allow you to launch via automation and to specify
openCurrentDatabase()
knowing that it will shut down when the application does

#12

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in
news:KTi5o.50960$dx7.25141 (AT) newsfe21 (DOT) iad:

Quote:

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

....because Word, Outlook and Excel don't have runtime versions.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#13

On Sun, 1 Aug 2010 12:37:29 -0700 (PDT), Roger
<lesperancer (AT) natpro (DOT) com> wrote:

Quote:

but my point is, the access runtime knows (should know the difference)
between launched from explorer vs launched from automation

How can it?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

#14

On 5 Aug., 01:52, Tony Toews wrote:

Quote:

On Sun, 1 Aug 2010 12:37:29 -0700 (PDT), Roger wrote:
but my point is, the access runtime knows (should know the difference)
between launched from explorer vs launched from automation

How can it?

I remember the old times of DOS and Assembler when we had tricks to
find out whether the program had been launched from within a batch or
by command.com or whatever. So I suppose Microsoft could fix the
problem if they only wanted.

But I wonder how Roger happened to be the first person to stumble into
this difficulty since when the first runtime for Access hit the
market, wasn't it Access 2000?

The only reason I can imagine why he needs to programmatically modify
from outside existing reports and forms would be that he has back end
and front end in one file, so this one is the only way to deliver new
versions of the program to customers without overwriting their data.
Maybe I'm mistaked?

Greetings
Marco P

#15

"Marco Pagliero" <martesi (AT) web (DOT) de> wrote

Quote:

But I wonder how Roger happened to be the first person to stumble into
this difficulty since when the first runtime for Access hit the
market, wasn't it Access 2000?

There have been runtimes since Access 2.0

Quote:

The only reason I can imagine why he needs to programmatically modify
from outside existing reports and forms would be that he has back end
and front end in one file, so this one is the only way to deliver new
versions of the program to customers without overwriting their data.
Maybe I'm mistaked?

If that's the case, then he should fix his application so it's properly
split.

--
Doug Steele, Microsoft Access MVP
http://www.AccessMVP.com/DJSteele
Co-author: Access 2010 Solutions, published by Wiley
(no e-mails, please!)

#16

On Aug 5, 6:22*am, Marco Pagliero <mart... (AT) web (DOT) de> wrote:

Quote:

On 5 Aug., 01:52, Tony Toews wrote:

On Sun, 1 Aug 2010 12:37:29 -0700 (PDT), Roger wrote:
but my point is, the access runtime knows (should know the difference)
between launched from explorer vs launched from automation

How can it?

I remember the old times of DOS and Assembler when we had tricks to
find out whether the program had been launched from within a batch or
by command.com or whatever. So I suppose Microsoft could fix the
problem if they only wanted.

But I wonder how Roger happened to be the first person to stumble into
this difficulty since when the first runtime for Access hit the
market, wasn't it Access 2000?

The only reason I can imagine why he needs to programmatically modify
from outside existing reports and forms would be that he has back end
and front end in one file, so this one is the only way to deliver new
versions of the program to customers without overwriting their data.
Maybe I'm mistaked?

Greetings
Marco P

all my data is on sqlserver 2005, so I only have frontends
I have many front end applications that need to inter communication
for example, I have a quoting application that needs to report a
quality issue (QMS)
the QMS system is it's own application

so in access97, the quoting application uses this function
Dim obj As Access.Application

On Error GoTo fErr
Set obj = New Access.Application
With obj
.Visible = True
.RefreshTitleBar
.OpenCurrentDatabase "another.mdb"
.run "createQMS"
end with

to start to QMS application and run a function that opens a form to
create a new quality problem

I have other applications that interoperate this way

with access2007, I've found that I can SHELL to start the QMS
application, and I can use the command line to pass in the function to
run, with parameter

and the QMS application's autoexec macro parses out the command line
and behaves accordingly

#17

Marco Pagliero <martesi (AT) web (DOT) de> wrote in
news:9c8456ec-d164-4adf-a65a-3ef8ca360343 (AT) u26g2000yqu (DOT) googlegroups.co
m:

Quote:

when the first runtime for Access hit the
market, wasn't it Access 2000?

The runtime existed at least for Access 2, though it was called the
ADT (Access Developers Toolkit). I don't know when it was
implemented, but it was already a mature platform by that point.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#18

Roger <lesperancer (AT) natpro (DOT) com> wrote in
news:45e59b82-c838-4ed2-a681-378709b93915 (AT) q21g2000prm (DOT) googlegroups.co
m:

Quote:

all my data is on sqlserver 2005, so I only have frontends
I have many front end applications that need to inter
communication for example, I have a quoting application that needs
to report a quality issue (QMS)
the QMS system is it's own application

so in access97, the quoting application uses this function
Dim obj As Access.Application

On Error GoTo fErr
Set obj = New Access.Application
With obj
.Visible = True
.RefreshTitleBar
.OpenCurrentDatabase "another.mdb"
.run "createQMS"
end with

to start to QMS application and run a function that opens a form
to create a new quality problem

I would never do this kind of thing. Do you not know about
Application.Run? It's how you implement an add-in, and there are
lots of possibilies there that would not require automating the
other application.

Of course, how hard that is to implement would depend on the level
of complexity of what you're using from the other application, as
well as various issues with what data to use and so forth, but all
of those are issues that can be addressed and still work with the
runtime.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#19

On Aug 5, 12:49*pm, "David W. Fenton" <NoEm... (AT) SeeSignature (DOT) invalid>
wrote:

Quote:

Roger <lesperan... (AT) natpro (DOT) com> wrote innews:45e59b82-c838-4ed2-a681-378709b93915 (AT) q21g2000prm (DOT) googlegroups.co
m:

all my data is on sqlserver 2005, so I only have frontends
I have many front end applications that need to inter
communication for example, I have a quoting application that needs
to report a quality issue (QMS)
the QMS system is it's own application

so in access97, the quoting application uses this function
*Dim obj As Access.Application

* * On Error GoTo fErr
* * Set obj = New Access.Application
* * With obj
* * * * .Visible = True
* * * * .RefreshTitleBar
* * * * .OpenCurrentDatabase "another.mdb"
* * * * .run "createQMS"
* * end with

to start to QMS application and run a function that opens a form
to create a new quality problem

I would never do this kind of thing. Do you not know about
Application.Run? It's how you implement an add-in, and there are
lots of possibilies there that would not require automating the
other application.

Of course, how hard that is to implement would depend on the level
of complexity of what you're using from the other application, as
well as various issues with what data to use and so forth, but all
of those are issues that can be addressed and still work with the
runtime.

--
David W. Fenton * * * * * * * * *http://www.dfenton.com/
contact via website only * *http://www.dfenton.com/DFA/- Hide quoted text -

- Show quoted text -

in access97, application.run is what I used to run a function in
another MDB application (per my code sample)

application.run doesn't work with the runtime cause I can't create a
new access.application

#20

Roger <lesperancer (AT) natpro (DOT) com> wrote in
news:1196cefb-3a29-493e-8942-a146317a6df5 (AT) x21g2000yqa (DOT) googlegroups.co
m:

Quote:

On Aug 5, 12:49*pm, "David W. Fenton" <NoEm...
I would never do this kind of thing. Do you not know about
Application.Run? It's how you implement an add-in, and there are
lots of possibilies there that would not require automating the
other application.

Of course, how hard that is to implement would depend on the
level of complexity of what you're using from the other
application, as well as various issues with what data to use and
so forth, but all of those are issues that can be addressed and
still work with the runtime.

in access97, application.run is what I used to run a function in
another MDB application (per my code sample)

application.run doesn't work with the runtime cause I can't create
a new access.application

You don't *need* to create a new application to use Application.Run
-- you're running code/forms/reports in another database, but in a
single instance of Access.

Consider the fact that DBEngine.Databases is a collection that can
have more than one database in it. When you use Application.Run, you
are opening another database with the existing instance of Access,
so that DBEngine.Databases.Count should be 2 (or more, perhaps),
with one being the CurrentDB open in the user interface, and the
other being the database with the code/forms/reports being executed
via Application.Run.

That's the whole point of my mentioning it, because it entirely
avoids the problem with the runtime of being unable to initialize
another instance of Access -- you don't *need* another instance,
because you're using the stuff from the other database within the
original instance of Access.

This is not to say it's *easy* to do that (if you need forms that
are bound to linked tables, you have to have the same linked tables
in the CurrentDB database as they are bound to in the external
database you're using via Application.Run). But it is at least
*possible*, whereas initiating another instance of the runtime
isn't.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/