Some XP machines allow database window to display - others not

[MLH]

I use this line

DoCmd.SelectObject acTable, "tblAdmin", True

when I want to display database window. Often-
times, working on a remote mde via a TCP/IP
connection, its convenient to have a look at
at the database window, open tables, make
changes.

Can someone tell me why some runtime installations
will open the database window and others won't?
I do all my installs are pretty much the same way.
I haven't a clue that would account for the
behavioural differences.

[Rick Brandt]

MLH wrote:

I use this line

DoCmd.SelectObject acTable, "tblAdmin", True

when I want to display database window. Often-
times, working on a remote mde via a TCP/IP
connection, its convenient to have a look at
at the database window, open tables, make
changes.

Can someone tell me why some runtime installations
will open the database window and others won't?
I do all my installs are pretty much the same way.
I haven't a clue that would account for the
behavioural differences.

The ones that work are not runtime installations. Displaying the db window
is not supported in the runtime. You can build a form of your own that
gives similar information though and that would display.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Granny Spitz via AccessMonster.com]

MLH wrote:

Can someone tell me why some runtime installations
will open the database window and others won't?

The Access runtime version doesn't allow the database window to show, so if
you're seeing it, this means the computer has another version of Access
installed, and your app is running in *that* version, not the runtime version
you expected. If this comes as a surprise to you, then that's bad because it
means one of two things:

1) The user installed another version of Access *after* your runtime was
installed, which can lead to compatibility problems, especially if an older
version of Access was installed after the newer version, or

2) Your runtime installation didn't check for other versions of Access
before installing, which can also lead to compatibility problems.

Compatibility problems lead to higher tech support custs, which means it
either comes out of your pocket or the customer's.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200611/1

[MLH]

10:4
That's probably what I'll do.

I've done a runtime distribution rollout at 2 sites
that allow the DB window to display. They do
have Access 97 installed on that same system.
I checked the properties of the desktop icon
launching the application and it reads:
"c:\program files\AppDir\AppName.mde"
The installation process DID create the following
directory: c:\program files\AppDir\Office and
MSACCESS.EXE is listed in there. But its also
located at c:\program files\microsoft office\ and
I can't say for certain which is being used.

When I did my runtime install, I might have later
opened their copy of A97, attached to my runtime
supplied system database and opened the primary
MDE included in the RT distribution to do some
routine maintenance.

Just out-a-curiousity, are there special concerns
I should be aware of when performing a run-time
installation of an A97 created app onto a machine
that currently has Access 97 installed? I don't think
customers would appreciate it very much if I some-
how replaced their
C:\Program Files\Microsoft Office\Office\msAccess.exe
file.

[MLH]

<snip>
This installation is a number of years old now. Dunno for sure which
is the case, but I suspact A97 was added later. Will keep fingers
crossed. So far, so good. Apparently the MDE has NO problem running
in the quasi-runtime bastardized environment. App functions normally
with the exception of that database window thing. That was handy
and may turn out to be again. So I'm not gonna worry about that. Only
admin-level users can launch the button and open the DB window.

Anything else I should be on the lookout for?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxx

>The Access runtime version doesn't allow the database window to show, so if
you're seeing it, this means the computer has another version of Access
installed, and your app is running in *that* version, not the runtime version
you expected. If this comes as a surprise to you, then that's bad because it
means one of two things:

1) The user installed another version of Access *after* your runtime was
installed, which can lead to compatibility problems, especially if an older
version of Access was installed after the newer version, or

2) Your runtime installation didn't check for other versions of Access
before installing, which can also lead to compatibility problems.

Compatibility problems lead to higher tech support custs, which means it
either comes out of your pocket or the customer's.

[Granny Spitz via AccessMonster.com]

MLH wrote:

Apparently the MDE has NO problem running
in the quasi-runtime bastardized environment.

If it's an MDE file and they're opening it with their retail version, it
means they're opening it with Access 97, not a later version which can cause
compatibility issues. But I can't think of a logical reason to have *both*
the retail and the runtime version of Access 97 installed on the same
computer.

Anything else I should be on the lookout for?

I've never installed both the runtime and the retail edition of the same
version of Access on a computer, so I don't know. Most of the compatibility
issues expected with runtime vs retail come from different Office versions,
like Office 97 vs Office 2000. At the least your customers have wasted disk
space, but beyond that I can't think of what else might cause you a headache.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200611/1

[Rick Brandt]

"MLH" <CR**@NorthState.netwrote in message
news:bk********************************@4ax.com...

10:4
That's probably what I'll do.

I've done a runtime distribution rollout at 2 sites
that allow the DB window to display. They do
have Access 97 installed on that same system.
I checked the properties of the desktop icon
launching the application and it reads:
"c:\program files\AppDir\AppName.mde"
The installation process DID create the following
directory: c:\program files\AppDir\Office and
MSACCESS.EXE is listed in there. But its also
located at c:\program files\microsoft office\ and
I can't say for certain which is being used.

When I did my runtime install, I might have later
opened their copy of A97, attached to my runtime
supplied system database and opened the primary
MDE included in the RT distribution to do some
routine maintenance.

Just out-a-curiousity, are there special concerns
I should be aware of when performing a run-time
installation of an A97 created app onto a machine
that currently has Access 97 installed? I don't think
customers would appreciate it very much if I some-
how replaced their
C:\Program Files\Microsoft Office\Office\msAccess.exe
file.

Unless you are using a custom installer this shouldn't happen. The runtime
installer for Access 97 will not install the runtime on a PC that already has
Access 97 on it. The inverse is also true. If the retail version is installed
after the runtime then it should "see" the runtime install and use the same
folder.

If you used a custom installer and/or Sagekey scripts then perhaps none of the
above applies.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[MLH]

Thx Rick. That's useful info. I still use A97. I like it and its the
only one I know how to use. Been so long since I looked at
that guy's machine. Can't recall much about it.

By "will not install the runtime on a PC", you mean will not installl
a redundant copy of the msAccess.exe file on a PC, right? The same exe
is used for both runtime and retail versions of A97. The runtime APP
itself WILL install, of course. (just to eliminate any confusion on
the valid point you made).

>
Unless you are using a custom installer this shouldn't happen. The runtime
installer for Access 97 will not install the runtime on a PC that already has
Access 97 on it. The inverse is also true. If the retail version is installed
after the runtime then it should "see" the runtime install and use the same
folder.

If you used a custom installer and/or Sagekey scripts then perhaps none of the
above applies.