Prev: is this valid xml for a custom QAT
Next: Edanmo's Storage Class
From: Roger on 1 Aug 2010 15:37
On Aug 1, 12:18 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...(a)msn.com>
wrote:
> "Salad" <sa...(a)oilandvinegar.com> wrote in message
>
> news:zfCdnU9tHNNIHsjRnZ2dnUVZ_u-dnZ2d(a)earthlink.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
From: David W. Fenton on 1 Aug 2010 20:57
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in
news:KTi5o.50960$dx7.25141(a)newsfe21.iad:

> 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/
From: Tony Toews on 4 Aug 2010 19:52
On Sun, 1 Aug 2010 12:37:29 -0700 (PDT), Roger
<lesperancer(a)natpro.com> wrote:

>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/
From: Marco Pagliero on 5 Aug 2010 08:22
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
From: Douglas J. Steele on 5 Aug 2010 11:57
"Marco Pagliero" <martesi(a)web.de> wrote in message
news:9c8456ec-d164-4adf-a65a-3ef8ca360343(a)u26g2000yqu.googlegroups.com...
> 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

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



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: is this valid xml for a custom QAT
Next: Edanmo's Storage Class