Was the A97 runtime setup wizard in the ODE tools something MicroSoft begrudgingly offered?

[MLH]

I am concerned.

I have recently moved to A97 from Access 2.0 where I rolled out
runtime apps with the ADT. Now, the Office Pro Developer's
Edition with Access 97 is what I'm using. I find some unfriendly
behavior. I want (need) to find out what the pro's (like you guys)
are doing to circumvent some of the difficulties encountered when
rolling out A97 runtime apps into environments that either have or
may have in the future MS Access 97 retail installed.

Example:
I installed an A97 runtime app onto a Win98 box that was minimally
configured. It had the OS and that's about it. No MS Office or Access
or anything like that. The app installed and with some massaging,
worked acceptably. The installation built the following dir's...
c:\Program Files\TowPack\
c:\Program Files\TowPack\Office (because no prev Office installed)
c:\Program Files\TowPack\Setup

Then, I needed to do some testing - uncover any missing REFERENCES
and such as that. So, I installed MS Access 97 from the ODE disk. The
first thing I noticed is that I lost my app's link to the system
database needed for the user-specific information. The Office
install procedure thoughtlessly disregarded that. My app, of course,
booted w/o asking for user login ID. Additionally, the runtime
environment that sort of hides the fact that msaccess.exe is running
the database had been scrapped. "MS Access" was clearly showing
in the title bar. I tried reinstalling the runtime app afterward -
that didn't help much. I uninstalled Office and it completely removed
c:\Program Files\TowPack\MSAccess.exe - rendering my runtime
application useless.

I don't consider these to be thoughtful and friendly gestures. I take
they've never been addressed, let alone fixed by the Access developer
team? But then, I don't know. I'm new to A97 and am writing to ask
you guys what sort of game plan you use as work-arounds.

[Terry Kreft]

If your app booted and was useable when it was pointing at the wrong system
db then you haven't secured it properly.

If you didn't install a renamed system db and you put it where the office
setup would install the system db then it will get overwritten.

If you've got Microsoft Access showing in the title bar then I'm guessing
you haven't used the Startup properties to set the Application Title
property.

If you uninstall Office and the msaccess.exe is installed where you had your
runtime installed then it will remove msaccess, it's an application not a
shared utility file.
--
Terry Kreft
MVP Microsoft Access
"MLH" <CR**@NorthState.net> wrote in message
news:i7********************************@4ax.com...

I am concerned.

I have recently moved to A97 from Access 2.0 where I rolled out
runtime apps with the ADT. Now, the Office Pro Developer's
Edition with Access 97 is what I'm using. I find some unfriendly
behavior. I want (need) to find out what the pro's (like you guys)
are doing to circumvent some of the difficulties encountered when
rolling out A97 runtime apps into environments that either have or
may have in the future MS Access 97 retail installed.

Example:
I installed an A97 runtime app onto a Win98 box that was minimally
configured. It had the OS and that's about it. No MS Office or Access
or anything like that. The app installed and with some massaging,
worked acceptably. The installation built the following dir's...
c:\Program Files\TowPack\
c:\Program Files\TowPack\Office (because no prev Office installed)
c:\Program Files\TowPack\Setup

Then, I needed to do some testing - uncover any missing REFERENCES
and such as that. So, I installed MS Access 97 from the ODE disk. The
first thing I noticed is that I lost my app's link to the system
database needed for the user-specific information. The Office
install procedure thoughtlessly disregarded that. My app, of course,
booted w/o asking for user login ID. Additionally, the runtime
environment that sort of hides the fact that msaccess.exe is running
the database had been scrapped. "MS Access" was clearly showing
in the title bar. I tried reinstalling the runtime app afterward -
that didn't help much. I uninstalled Office and it completely removed
c:\Program Files\TowPack\MSAccess.exe - rendering my runtime
application useless.

I don't consider these to be thoughtful and friendly gestures. I take
they've never been addressed, let alone fixed by the Access developer
team? But then, I don't know. I'm new to A97 and am writing to ask
you guys what sort of game plan you use as work-arounds.

[MLH]

Excuse me, previous post erroneously stated that MSAccess.exe
was removed from c:\program files\towpack\ and that is not true.
Here's how the post should have read...

I am concerned.

I have recently moved to A97 from Access 2.0 where I rolled out
runtime apps with the ADT. Now, the Office Pro Developer's
Edition with Access 97 is what I'm using. I find some unfriendly
behavior. I want (need) to find out what the pro's (like you guys)
are doing to circumvent some of the difficulties encountered when
rolling out A97 runtime apps into environments that either have or
may have in the future MS Access 97 retail installed.

Example:
I installed an A97 runtime app onto a Win98 box that was minimally
configured. It had the OS and that's about it. No MS Office or Access
or anything like that. The app installed and with some massaging,
worked acceptably. The installation built the following dir's...
c:\Program Files\TowPack\
c:\Program Files\TowPack\Office (because no prev Office installed)
c:\Program Files\TowPack\Setup

Then, I needed to do some testing - uncover any missing REFERENCES
and such as that. So, I installed MS Access 97 from the ODE disk. The
first thing I noticed is that I lost my app's link to the system
database needed for the user-specific information. The Office
install procedure thoughtlessly disregarded that. My app, of course,
booted w/o asking for user login ID. Additionally, the runtime
environment that sort of hides the fact that msaccess.exe is running
the database had been scrapped. "MS Access" was clearly showing
in the title bar. I tried reinstalling the runtime app afterward -
that didn't help much. I uninstalled Office and although it did not
remove c:\Program Files\TowPack\Office\MSAccess.exe, it did
render my runtime application useless by breaking the file association
link to the mde database file. Dbl-clicking the application icon now
prompts user to associate the file and the bad part is that MS Access
does not even appear in the list after uninstalling Office.

I don't consider these to be thoughtful and friendly gestures. I take
it they've never been addressed, let alone fixed by the Access
development team? But then, I don't know. I'm new to A97 and am
writing to ask you guys what sort of game plan you use as
work-arounds.

[Rick Brandt]

MLH wrote:

I am concerned.

I have recently moved to A97 from Access 2.0 where I rolled out
runtime apps with the ADT. Now, the Office Pro Developer's
Edition with Access 97 is what I'm using. I find some unfriendly
behavior. I want (need) to find out what the pro's (like you guys)
are doing to circumvent some of the difficulties encountered when
rolling out A97 runtime apps into environments that either have or
may have in the future MS Access 97 retail installed.

Example:
I installed an A97 runtime app onto a Win98 box that was minimally
configured. It had the OS and that's about it. No MS Office or Access
or anything like that. The app installed and with some massaging,
worked acceptably. The installation built the following dir's...
c:\Program Files\TowPack\
c:\Program Files\TowPack\Office (because no prev Office installed)
c:\Program Files\TowPack\Setup

Then, I needed to do some testing - uncover any missing REFERENCES
and such as that. So, I installed MS Access 97 from the ODE disk. The
first thing I noticed is that I lost my app's link to the system
database needed for the user-specific information. The Office
install procedure thoughtlessly disregarded that.
You were expecting a full install of Office to honor the registry settings
of a previous runtime app? What if there had been a runtime app on that
machine before you came along? Would you have expected to live with its
settings?

Your install program should be creating shortcuts that explicitly point to
your MSAccess.exe and workgroup files rather than just relying on the
Windows registry settings.
My app, of course,
booted w/o asking for user login ID.
Then it was never secured properly. When using the wrong workgroup the file
should refuse to open.
Additionally, the runtime
environment that sort of hides the fact that msaccess.exe is running
the database had been scrapped. "MS Access" was clearly showing
in the title bar.
Does your app not have a startup option to specify an application name? Do
you not include the /Runtime command line argument in your shortcut?
I tried reinstalling the runtime app afterward -
that didn't help much. I uninstalled Office and it completely removed
c:\Program Files\TowPack\MSAccess.exe - rendering my runtime
application useless. I don't consider these to be thoughtful and friendly gestures. I take
they've never been addressed, let alone fixed by the Access developer
team? But then, I don't know. I'm new to A97 and am writing to ask
you guys what sort of game plan you use as work-arounds.

There are definitely issues with the runtime and the fully licensed version
co-existing, but most of the problems are when the licensed instance is not
the same Office version. Most of the issues you are describing are easily
addressed by fixing your setup program.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[MLH]

OK. Whew, its clear now that most of my concerns can be fixed and
were apparently not MS oversights. I'm relieved. I do have some
things to brush up on - mainly security.

If your app booted and was useable when it was pointing at the wrong system
db then you haven't secured it properly. Oops... I think you're right about that. I'm not exactly sure how to
set up security to where the database refuses to open w/o the
correct system mdw in place.
If you didn't install a renamed system db and you put it where the office
setup would install the system db then it will get overwritten. I did have an alternately named system database, so it was preserved.
But, of course, the new install of office and MS Access set up the
default system database upon installation.
If you've got Microsoft Access showing in the title bar then I'm guessing
you haven't used the Startup properties to set the Application Title
property. Startup properties? Are they mdb-specific? Should I set them up in the
mdb file before compiling the mde?
If you uninstall Office and the msaccess.exe is installed where you had your
runtime installed then it will remove msaccess, it's an application not a
shared utility file.

That was my mistake in the first post. I apologize. The MS Access
executable was preserved - not removed. It was left there in
c:\program files\towpack\office\ ==> just where it was when
the original runtime app put it there.

[MLH]

<snip>

You were expecting a full install of Office to honor the registry settings
of a previous runtime app? What if there had been a runtime app on that
machine before you came along? Would you have expected to live with its
settings? Well, not exactly. Truth is, I didn't know what to expect. I'm new to
all of this and I don't know much about registry settings and the
like.

Your install program should be creating shortcuts that explicitly point to
your MSAccess.exe and workgroup files rather than just relying on the
Windows registry settings. You're exactly right. Now that's something I don't know how to do. I
just let the A97 runtime setup wizard do the obvious. Exactly how does
one go about building the installation filese for the runtime
distribution to do that? It must be something I overlooked. Could you
give me an example if both my mde and mdw are located in
c:\program files\towpack and are named towpack.mde and system.mdw
respectively?

My app, of course,
booted w/o asking for user login ID.
Then it was never secured properly. When using the wrong workgroup the file
should refuse to open.

Additionally, the runtime
environment that sort of hides the fact that msaccess.exe is running
the database had been scrapped. "MS Access" was clearly showing
in the title bar.

Does your app not have a startup option to specify an application name? Do
you not include the /Runtime command line argument in your shortcut?

That one went right by me too. Sorry about that. So, should I go back
to my SOUCE mdb file to configure a startup option to specify
application name? Never have done that. Help appreciated there.
And as for a /Runtime command-line argument - no. I couldn't ever
get right syntax for it. Right clicking my shortcut and looking at the
properties shows c:\program files\towpack\towpack.mde as the complete
launch string. And, it is wrapped in quotes. Where should I put the
/Runtiime parm? And how about the system database spec?

I tried reinstalling the runtime app afterward -
that didn't help much. I uninstalled Office and it completely removed
c:\Program Files\TowPack\MSAccess.exe - rendering my runtime
application useless.

I don't consider these to be thoughtful and friendly gestures. I take
they've never been addressed, let alone fixed by the Access developer
team? But then, I don't know. I'm new to A97 and am writing to ask
you guys what sort of game plan you use as work-arounds.

There are definitely issues with the runtime and the fully licensed version
co-existing, but most of the problems are when the licensed instance is not
the same Office version. Most of the issues you are describing are easily
addressed by fixing your setup program.

Many thanks! I've certainly got some homework to do there. I have
missed out on taking full advantage of some the control I did not
realize was there in the setup program.

[Rick Brandt]

MLH wrote:

Your install program should be creating shortcuts that explicitly
point to your MSAccess.exe and workgroup files rather than just
relying on the Windows registry settings.

You're exactly right. Now that's something I don't know how to do. I
just let the A97 runtime setup wizard do the obvious. Exactly how does
one go about building the installation filese for the runtime
distribution to do that? It must be something I overlooked.

The second or third step in the setup wizard offers...

* I would like to use a wizard-provided command line
* I would like to specify my own custom command line

On that same step on the { Database Shortcut Properties } page there are
Checkboxes that will automatically add the workgroup file to the shortcut as
well as options for the /Runtime /Profile and /Excl arguments.

The wizard uses these various "markers" as sort of wildcards for...

$(FilePath)
$(WinPath)
$(WinSysPath)
$(AppPath)
$(WorkgroupFile)

....so they don't have to be hard-coded.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:i7********************************@4ax.com:

I have recently moved to A97 from Access 2.0 where I rolled out
runtime apps with the ADT. Now, the Office Pro Developer's
Edition with Access 97 is what I'm using. I find some unfriendly
behavior. I want (need) to find out what the pro's (like you guys)
are doing to circumvent some of the difficulties encountered when
rolling out A97 runtime apps into environments that either have or
may have in the future MS Access 97 retail installed.

I own the ODE but not once have I even contemplated distruting a
runtime.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[MLH]

I'm gonna give it a try. So far, its been a bear. But there's light at
the end of the tunnel. Tiny, unsuspected things like this error I've
been having with the mde file being created with +R file attribute
(because I copied it to a CD-ROM for distribution, I believe) keep
sneaking up on me. Its terribly confusing.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx

I own the ODE but not once have I even contemplated distruting a
runtime.

[Larry Linson]

"MLH" <CR**@NorthState.net> wrote

. . . Tiny, unsuspected things like this
error I've been having with the mde file
being created with +R file attribute
(because I copied it to a CD-ROM for
distribution, I believe) keep sneaking up
on me. Its terribly confusing.

Any file copied from a CD will be flagged Read-Only. It is a characteristic
of the CD-ROM media, and has nothing to do with the Office Developer Edition
tools.

But, it is true that the runtime support is so large that you can't
distribute on diskettes any longer (even if you have a diskette drive on
your machine -- my newest machine didn't include one).

My work is all unsecured samples or "bespoke" systems for specific clients,
so I have not actually distributed with the runtime. My clients, so far,
have been enthusiastic Office users and have had Office Pro (that is,
including Access) on every desktop where the databases would be used (I
don't think every employee had Access, but "informaton workers" did).

Larry Linson
Microsoft Access MVP

[MLH]

Well, there you have it. That's the answer, alright. Thx Larry.

Any file copied from a CD will be flagged Read-Only. It is a characteristic
of the CD-ROM media, and has nothing to do with the Office Developer Edition
tools.

But, it is true that the runtime support is so large that you can't
distribute on diskettes any longer (even if you have a diskette drive on
your machine -- my newest machine didn't include one).

My work is all unsecured samples or "bespoke" systems for specific clients,
so I have not actually distributed with the runtime. My clients, so far,
have been enthusiastic Office users and have had Office Pro (that is,
including Access) on every desktop where the databases would be used (I
don't think every employee had Access, but "informaton workers" did).

Larry Linson
Microsoft Access MVP