Runtime, more questions

[google3luo359]

OK, I'm trying to get a better understanding of the steps required to
get an app running in a runtime environment from a server, on a bunch
of networked front-ends.

I assume the first step would be to install the runtime Access on the
server.
How would I then split the db and create the front-end .mde's?

Is it the same process as for a full version of Access?
Does runtime Access allow you to split, and create mde's?

Thanks in advance!

Ric

 

[Allen Browne]

You cannot do any development work in a runtime version of Access.

Use the full version to split your database, and create the mde.

To give you an understanding of what the runtime is like to use, create a
shortcut to msaccess and your database, using the /runtime switch. The
target of the shortcut will be something like this:
"c:\Program Files\Microsoft office\office\msaccess.exe" /runtime
"c:\MyPath\MyDatabase.mdb"

 

[Albert D.Kallal]

I assume the first step would be to install the runtime Access on the

server.

No, not at all. Remember when you place a word file, or Excel file on the
server, it is YOUR PC that STILL has the sfotware installed.

You don't have to install word on the server just bacuase you have a shared
folder with some word docuemtns in it.

The sample applies to ms-access (which is part of office). You are simply
sharing a file. That file can be a word file, a Excel file, or a ms-access
data file. The software is STILL inssteedd on EACH pc....

Is it the same process as for a full version of Access?
Yes

Does runtime Access allow you to split, and create mde's?

Not really. You must develop your application using the full version of
ms-access. The runtime only allows you to run the resulting mde file that
you create. That mde can also be run using the full version of ms-access.

 

[google3luo359]

Hi Albert and Allen,

Thanks for helping out, you guys are really great,

I have Access 2000 and will be purchasing Access 2002 Dev. kit soon so
I'd like to know what to expect and how to set things up when I'll have
the software.

I guess I should have posted my questions as a follow-up to this
thread:

http://groups.google.com/group/[email protected]+&rnum=3#91034ce9e2350c62

Albert, in the above thread I already received advice from John Vinson
to install a runtime on the server, rather than on ~50 front-end PC's.
That is why I made the statement below about my first step.

The sample applies to ms-access (which is part of office). You are simply
sharing a file. That file can be a word file, a Excel file, or a ms-access
data file. The software is STILL inssteedd on EACH pc....

You see, Access is not on *any* of the computers, so I can't share my
..mdb file.

Since I now have learned that I must split and create my mde's on my
Access computer, that will mean doing this at home. I can't be the
first with this situation.
How do I split with a backend on G:\ (that's where the .mdb will
reside at work) when at home I have no G:\ drive?

TIA Ric

 

[Rick Brandt]

Hi Albert and Allen,

Thanks for helping out, you guys are really great,

I have Access 2000 and will be purchasing Access 2002 Dev. kit soon so
I'd like to know what to expect and how to set things up when I'll
have the software.

I guess I should have posted my questions as a follow-up to this
thread:

http://groups.google.com/group/[email protected]+&rnum=3#91034ce9e2350c62

Albert, in the above thread I already received advice from John Vinson
to install a runtime on the server, rather than on ~50 front-end PC's.
That is why I made the statement below about my first step.

That is not what John meant. He meant that you could put your install
program on the server and then run that from each PC to get the runtime
installed on each and every PC that needs it rather than having to walk
around with a CD to do it.

 

[google3luo359]

That is not what John meant. He meant that you could put your install
program on the server and then run that from each PC to get the runtime
installed on each and every PC that needs it rather than having to walk
around with a CD to do it.

Ahh... I see. Thanks Rick. I had interpreted his help in a completely
different way!
So if I understand correctly now, I first install the program on the
server, then install a
runtime on each PC, via the server.
Then I'd install an .mde on each front-end PC.
Can I make the .mde's from the server-installed program or do I have to
do that at home?

TIA Ric

 

[Rick Brandt]

Ahh... I see. Thanks Rick. I had interpreted his help in a completely
different way!
So if I understand correctly now, I first install the program on the
server, then install a
runtime on each PC, via the server.
Then I'd install an .mde on each front-end PC.
Can I make the .mde's from the server-installed program or do I have to
do that at home?

A runtime setup routine will normally install the runtime along with your
MDB/MDE file. In fact the licensing requires that an MDB/MDE file be included
in the package.

 

[Albert D.Kallal]

So if I understand correctly now, I first install the program on the

server, then install a
runtime on each PC, via the server.

No, you do NOT install it on the server, you place a copy of the install
package on the server. A big difference!!

Then I'd install an .mde on each front-end PC.

Well, you will eventually install a mde on each pc. However, before you do
that, you will have to install ms-access on each machine, or in fact
install the access runtime.

Remember, the runtime is really a full version of ms-access (with just some
design parts removed). The runtime for a2000 was 150 megs in size, and often
required a re-boot of the pc during the install. This whole process is NOT
MUCH different then installing the full version of ms-access on each pc. It
is a heavy, and large install package.

Can I make the .mde's from the server-installed program or do I have to
do that at home?

You just use the regular mde file you been using for a long time now during
testing (I assuming you have working application, and when you, or your
users have been testing this application, you been testing the mde ...right?
It is this mde that you place on each pc. Once ms-access (or the ms-access
runtime) is installed on that target pc, you simply copy the mde to that pc,
and it will run as usual.

Remember, you need ms-access, or the ms-access runtime installed on that
target pc. Once you done this, then you can simply double click on any mdb,
or mde you place on that target machine. There is nothing special about the
runtime except that you must provide your own custom menus (or use forms
with buttons on them), as the ms-access ones are absent.

 

[google3luo359]

Hi Albert,

I'm basically trying to figure out two things in these threads:
The mechanics of installing a runtime on a networked system and the
approximate time it will take to do it.

No, you do NOT install it on the server, you place a copy of the install
package on the server. A big difference!!

OK, I see. So that would involve copying all the files from the Access
Devel. CD to the server, or just certain files?

Remember, the runtime is really a full version of ms-access (with just some
design parts removed). The runtime for a2000 was 150 megs in size, and often
required a re-boot of the pc during the install. This whole process is NOT
MUCH different then installing the full version of ms-access on each pc. It
is a heavy, and large install package.

OK, this is a completely different picture than was painted by Rick
Brandt in a previous thread. He suggested it would take "a couple
minutes" to install on each front-end PC.
A heavy large install package in addition to a reboot sounds like a
_minimum of five, probably closer to ten minutes per PC. With 50 PC's
we're talking more than a full day's work just to install.

You just use the regular mde file you been using for a long time now during
testing (I assuming you have working application, and when you, or your
users have been testing this application, you been testing the mde ...right?
It is this mde that you place on each pc. Once ms-access (or the ms-access
runtime) is installed on that target pc, you simply copy the mde to that pc,
and it will run as usual.

There is a problem however. The regular .mde that I have been using at
home during development is referring to a path that will not be used at
work. The work path will be on the G:\ drive. I have no G:\ drive at
home.

So how do I make an .mde for the front-end PC's, split to a G:\ path,
when I've been told that runtime Access won't allow the creation of
..mde's ???

Again, I can't imagine I'm the first one to encounter this problem.

TIA Ric

 

[Rick Brandt]

Hi Albert,

I'm basically trying to figure out two things in these threads:
The mechanics of installing a runtime on a networked system and the
approximate time it will take to do it.


OK, I see. So that would involve copying all the files from the Access
Devel. CD to the server, or just certain files?

No, the developer's tools allows you to create an install package. That package
installs the runtime plus your file. You place that package on the server.

OK, this is a completely different picture than was painted by Rick
Brandt in a previous thread. He suggested it would take "a couple
minutes" to install on each front-end PC.
A heavy large install package in addition to a reboot sounds like a
_minimum of five, probably closer to ten minutes per PC. With 50 PC's
we're talking more than a full day's work just to install.

I was talking about my Access 97 runtime install which takes only a minute or so
to run. The package for 2000 was large because it included Internet Explorer.
After many complaints a smaller package was provided by MS which no longer does
this. I have no idea how large the packages are for 2002 or 2003.

There is a problem however. The regular .mde that I have been using at
home during development is referring to a path that will not be used at
work. The work path will be on the G:\ drive. I have no G:\ drive at
home.

You should define all paths as UNC paths \\server\share rather then using mapped
drive letters. That way each client PC works without having to make the same
drive mapping. If you develop on a different LAN then you need to include a
code routine that allows the user to specify the path to the data file after
installation.

So how do I make an .mde for the front-end PC's, split to a G:\ path,
when I've been told that runtime Access won't allow the creation of
.mde's ???

You make the MDE with your fully licensed version and include that MDE file in
your installer package Users use the runtime to RUN the MDE. The user has no
need to create an MDE, only the means to run it.

 

[google3luo359]

Thanks Rick. I'm getting there slowly but surely.
For you guys who do this every day it seems like a cakewalk, but for
those who have never done it there are many things to learn, none
really all that intuitive.

No, the developer's tools allows you to create an install package. That package
installs the runtime plus your file. You place that package on the server.

I see. One more piece of the puzzle solved.

I was talking about my Access 97 runtime install which takes only a minute or so
to run. The package for 2000 was large because it included Internet Explorer.
After many complaints a smaller package was provided by MS which no longer does
this. I have no idea how large the packages are for 2002 or 2003.

I sure hope A2002 dev. has been streamlined again like A97.

You should define all paths as UNC paths \\server\share rather then using mapped
drive letters. That way each client PC works without having to make the same
drive mapping. If you develop on a different LAN then you need to include a
code routine that allows the user to specify the path to the data file after
installation.

How do I do this (define UNC paths) ?
I don't see the difference between mapped drive letters and UNC paths?
Could you explain it in just a little more detail?

You make the MDE with your fully licensed version and include that MDE file in
your installer package Users use the runtime to RUN the MDE. The user has no
need to create an MDE, only the means to run it.

Yes but when I make my .mde's they look to a specific path for the
split back-end file.
If I change or move the back-end file, the mde can no longer find it,
and another .mde must be made. This will be the case when I take my
split back-end file to the work environment.

TIA Ric

 

[Rick Brandt]

How do I do this (define UNC paths) ?
I don't see the difference between mapped drive letters and UNC paths?
Could you explain it in just a little more detail?

When you create your links you go through Network Neighborhood - Entire Network.
This creates a link path that looks like...

\\ServerName\ShareName\DataFile.mdb

The advantage is that this path works anywhere on the network without having to
map a drive letter (and worrying about someone messing with that mapping).

Yes but when I make my .mde's they look to a specific path for the
split back-end file.
If I change or move the back-end file, the mde can no longer find it,
and another .mde must be made. This will be the case when I take my
split back-end file to the work environment.

You do not have to make a new MDE to change where table links point. All you
have to do is provide a code routine that lets the user specify where the data
file is located. While form, report, and module design changes are not possible
in an MDE, changing table links can still be done. You should be able to easily
Google for code examples to set the links.

 

[google3luo359]

You do not have to make a new MDE to change where table links point. All you

have to do is provide a code routine that lets the user specify where the data
file is located. While form, report, and module design changes are not possible
in an MDE, changing table links can still be done. You should be able to easily
Google for code examples to set the links.

OK thanks very much for this info Rick.

 

[Albert D.Kallal]

I sure hope A2002 dev. has been streamlined again like A97.

Access 97 was about 12-14 megs in size.

The next best package was access 2003 runtime, and it is about 33 megs in
size (+ a few more IF YOU include the mde in the install).

So, as for the time to install? It would be the same as if you just
installed ms-access from the office cd. The 2002, and 2003 do NOT requite a
re-boot of the pc (at least in most cases...as my memory tells me).

So, it only takes a few minutes to install the runtime. I just wanted to
point out that it is a still a fairly large install.

Once the install is done, then for any additional updates, I don't use the
runtime distribution system, but simply use WinZip. And, now in fact I use
the open source Inno installer to create ms-access installs (after the
runtime has been installed).

Do remember, if those target machines have any other versions of ms-access
installed, then all of the MANY problems of running more then one version of
ms-access on a computer will still exist if you install the runtime, or full
version.

If your machines are controlled as to what software is going to be
installed, then the runtime package system is ok. However, if you expect to
have other versions of ms-access installed, then you need something MUCH
better, as the packaging wizard is VERY weak. You might consider purchasing
some install scripts. Do some reading here:

www.sagekey.com

 

[google3luo359]

Hi Albert,

Apart from size, do you have a preference between A2002 and A2003 Dev.
Kits?
I was leaning towards A2002 because it is backwards compatible to
Win98.

Do remember, if those target machines have any other versions of ms-access
installed, then all of the MANY problems of running more then one version of
ms-access on a computer will still exist if you install the runtime, or full
version.

None of the machines have any Access versions. Otherwise that would
greatly simplify this whole process. That's the reason behind going
with runtimes.

You might consider purchasing
some install scripts. Do some reading here:

www.sagekey.com

Thanks Albert.

Ric

 

[Albert D.Kallal]

Apart from size, do you have a preference between A2002 and A2003 Dev.

Kits?
I was leaning towards A2002 because it is backwards compatible to
Win98.

I never used the a2002. It does apparently *still* has the ability to
package activeX controls along with the installer. In the a2003 package
runtime, you LOST this ability. Since us developers avoided activeX controls
like the plague, then this loss is a minor issue to most of use. Further,
the a2003 runtime *always* installs the 6 supported activesX control that
ms-access support. So, you can freely use the listview, treeview, calander
control, and NEVER worry that it is not installed in the a2003.

However, if you use any 3rd party activeX controls, then you likely would
prefer the a2002 runtime as it still has support for activeX controls.

And, the a2002 is the LAST runtime that works al the way back to windows 98.

None of the machines have any Access versions. Otherwise that would
greatly simplify this whole process. That's the reason behind going
with runtimes.

Great!..then, you should well be able to use the runtime package wizard.