>> currentDb access.application

  • Thread starter Thread starter Jonathan
  • Start date Start date
J

Jonathan

Hi is there a way to reference the access.application object of the current
database?

I have more than one version on my machine. Even though I am running an
application in Access12 using set acApp=CreateObject("Access.Application12")
returns 11 for acApp.version

Many thanks,
Jonathan
 
funnily enough I got it just after posting this....

set acApp = Access.Application

doh!

Thanks anyway,
Jonathan
 
On Mon, 29 Dec 2008 19:51:01 -0800, Jonathan

Set acApp = CreateObject("Access.Application.12")
would likely have worked as well.

-Tom.
Microsoft Access MVP
 
Unfortunitely is was not as easy as that.

What I need is to open another session of an Access Application. Online help
suggests that you can open access12. However the object browser does not
include access12 as an option...

I seem to be going around and around this issue of having more than one
version of access installed so that I can support multiple access versions
(for example, you can only create a version 10 .mde using access10 otherwise
access10 cannot open the database. This is even though you can make changes
using access11).

Jonathan
 
Yes, running multiple versions can be a pain in the butt. Although I never
really had any problems until Access 2007 came along. Now it takes forever
to load 2007 after having used 2003 or XP.

--
Dale

email address is invalid
Please reply to newsgroup only.
 
Yes, running multiple versions can be a pain in the butt. Although I
never really had any problems until Access 2007 came along. Now it
takes forever to load 2007 after having used 2003 or XP.
Click to expand...

Do you have SP1 for 2007 installed yet? While the delay is still there
it is considerably shorter after SP1 is installed.
 
Rick,

I don't think so, but have not figured out how to determine what the current
SP is in 2007. What happened to the Help -> About menu option in Access 2007?

--
Dale

email address is invalid
Please reply to newsgroup only.
 
Rick,

I don't think so, but have not figured out how to determine what the
current SP is in 2007. What happened to the Help -> About menu option
in Access 2007?
Click to expand...

I have no freakin idea, but you can be sure that when you finally find it
it will be in a place that is actually easier to find than where it has
been for the last 15 years. I'm sure Microsoft has done numerous studies
proving that fact :-)
 
What I need is to open another session of an Access Application.
Click to expand...

My bet is that you actually don't need this at all.

Please explain why you think you *do* need it and perhaps someone
can provide you an approach that doesn't require another instance of
Access.

For what it's worth (and that's very little), I've made my living
programming Access applications since 1996 and have never even once
found a need to open another instance of Access from within Access.
 
Rick Brandt said:
I have no freakin idea, but you can be sure that when you finally find it
it will be in a place that is actually easier to find than where it has
been for the last 15 years. I'm sure Microsoft has done numerous studies
proving that fact :-)
Click to expand...

<guffaw>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
It's useful for opening forms and reports in other dbs,
Click to expand...

This can be done without opening another instance, if you have local
connections to the data they are based on (or for forms that are not
data bound).
automating macro
security when the user isn't allowed to change the macro security
setting to low,
Click to expand...

I would not consent to allowing one of my apps to run in that
environment, so wouldn't need it.
running functions in other dbs,
Click to expand...

This, again, can be done without opening another instance of Access
-- all the Access wizards work by precisely that method.
and building utilities that operate on
other dbs.
Click to expand...

I can't see what kinds of utilities would need to run in another
instance of Access in order to operate on other dbs.

Color me unconvinced that there's much need at all for anyone to
open another instance of Access from within Access.
 
I can't see what kinds of utilities would need to run in another
instance of Access in order to operate on other dbs.
Click to expand...

Here are a couple cases where I use automation.

I like to automate my build process in preparing a new install, to make it
faster, more robust, and more error-free. To my knowledge, the only way to
compile a front-end to a compiled .mde is using automation, using something
like: appAccess.SysCmd 603, strMdbFile, strMdeFile.

I like to perform automated testing of my front end during the build
process. For example, I open queries using a testing harness, display all
forms (partly to check for column widths and overlaps), and display all
reports. (Such testing can verify that there are no field renaming or table
renaming problems, for example.) Anything that requires DoCmd in the front
end requires automation, if you are running it from a testing or build
harness as a separate programmer tool. This is even more useful if you have
multiple front ends in your application, which might be installed for
different users but within the same build and/or install package.

- Steve
 
Opening another instance of Access isn't the only way to do those
things I mentioned. Library dbs can be used to accomplish the
same thing, but sometimes library dbs aren't practical.
Click to expand...

To me, opening another instance of Access is going to be a lot less
practical than a library database. I've distributed plenty of apps
with library databases, and never found any practical impediment to
doing so. I'd be interested in hearing what, exactly, you consider
those impediments might be.
 
Sky said:
Here are a couple cases where I use automation.

I like to automate my build process in preparing a new install, to
make it faster, more robust, and more error-free. To my knowledge,
the only way to compile a front-end to a compiled .mde is using
automation, using something like: appAccess.SysCmd 603,
strMdbFile, strMdeFile.
Click to expand...

In other words, as a *developer* you will automate other instances
of Access. I can see this, but not in a production app for end
users.

The only time I spent serious time trying to automate a second
instance of Access was in trying to use Lyle's
Application.SaveAsText 6 trick (which if run in the Access UI backs
up the data tables), but I could never get it to work, for some
reason.
I like to perform automated testing of my front end during the
build process. For example, I open queries using a testing
harness, display all forms (partly to check for column widths and
overlaps), and display all reports. (Such testing can verify that
there are no field renaming or table renaming problems, for
example.) Anything that requires DoCmd in the front end requires
automation, if you are running it from a testing or build harness
as a separate programmer tool. This is even more useful if you
have multiple front ends in your application, which might be
installed for different users but within the same build and/or
install package.
Click to expand...

Again, you're using it for development needs, not for production
applications.

If you could get the Application.SaveAsText 6 to work, I'd start
using it in my apps for backups of the back end, and then I'd
actually be finding it *useful* to automate another instance of
Access in a production app.
 
In other words, as a *developer* you will automate other instances
of Access. I can see this, but not in a production app for end
users.
Click to expand...

Even for the user, I do provide a menu selection to compact the front-end
database along with multiple back end databases, all in one operation. This
is accomplished by starting a new instance of access that waits for a few
seconds and then does the compacting, meanwhile shutting down the current
front-end instance.

- Steve
 
When the library db must stay as an mdb and the db referencing it
must become an mde
Click to expand...

Um, under what circumstances would that be the case? I can think of
one, and that's if you're using design mode in the MDB library, but
that's so bloody stupid as to not count as a reason.

Surely there's some more compelling reason for which you'd want to
distribute an MDB library? I've never distributed anything but an
MDE library, actually.
 
[quoting me:]
Even for the user, I do provide a menu selection to compact the
front-end database along
Click to expand...

Why would a front end ever need to be compacted? I can only think
that this would be a design error if it needed to be done regularly.
with multiple back end databases, all in one operation. This
is accomplished by starting a new instance of access that waits
for a few seconds and then does the compacting, meanwhile shutting
down the current front-end instance.
Click to expand...

I can't see any circumstances in which that would be useful in a
production app, unless the production app were wrongly-designed.
 
That fails with error 7996 if you have a linked table with an
invalid path or when the dsn is missing.
Click to expand...

Eh? Why would I have links in a back end?

Perhaps I didn't explain myself well enough.

I would like to use Lyle's trick to create full backups of the data
in a back end MDB, but I don't want to force the user to open the
back end in the Access UI to do it. The solution, it seems to me, is
to open the back end in another instance of Access, and issue the
SaveAsText 6 command, but I can never get it to work.

Since back ends usually don't have linked tables (the only time mine
ever do is during development, not in production use), I can't see
why you'd ever encounter the error for either reason you cite.
 
I can't see any circumstances in which that would be useful in a
production app, unless the production app were wrongly-designed.
Click to expand...

In my case, there is some bloating after the user installs a new version of
the application that has new structural changes in the backend tables. The
install process automatically rebuilds the user back-end tables to conform
with the newest dictionary of the application, possibly with new tables, new
fields, renamed fields, etc. The user data is preserved during the process,
which can cause some bloating.

These are analytic modeling applications, so they may have several
structural changes in a month when new features are added or prior features
modified based on customer requirements.

I do have some temporary tables for data import, but these are stored in
separate temporary databases that are copied from a clean template database,
so that does not cause any bloating. Same for model simulation output.

But automated restructuring of the user tables for a upgrade can cause some
bloating.

What procedure do you use to convert the user's backend data for upgrade? Do
you do it manually onsite? Do you compact it afterwards? I always do, using
an automated tool.

- Steve
 
Back
Top