Runtime For Dummies

[SMcK]

I posted on this subject back a couple weeks ago and learned enough to
know how much I don't know. I'm thinking I need to simplify and ask
fewer questions.

I've been creating Access databases on an occasional basis for about
12 years. I'm able to do most of what I need to do -- tables, forms,
queries, linking tables, creating subforms... I've had no experience
with creating runtime Access databases. I need to do that now. I'm
trying to understand how the whole runtime thing works.

Based on past experience with runtime programs from other
applications, I had believed:

-A runtime database is essentially a standalone file that contains all
components of the database as designed by the developer, plus enough
of the database engine to allow someone to use the database without
needing Access installed.

-This standalone file is all that need be distributed for the user to
use the database.

-The Developers toolkit, as purchased for earlier versions of Access,
or downloaded freely for A2007, would allow me to create this
standalone file.

-Having downloaded and installed the toolkit for A2007, it would be
relatively easy to figure out how to create this standalone file.

Can anyone help me understand the extent to which the above
assumptions are erroneous?

I would appreciate any help I could get in understanding how all this
works.

FWIW - The database that I want to distribute is relatively simple.
Currently it exists as a main table that contains all the data, and a
lookup table that is used to fill some of fields in the main table. I
may add a simple form at some point to allow users to see the data in
the table. The data will be entered to the database by syncing with a
PDA database where the data are originally collected. The system is
working (albeit not using a runtime Access database) with A2003. I've
created an A2007 version just by importing the A2003 version.

Thanks in advance,
-Scott

[CDMAPoster]

On Sep 26, 4:42 pm, SMcK <[e-mail]:

I posted on this subject back a couple weeks ago and learned enough to
know how much I don't know. I'm thinking I need to simplify and ask
fewer questions.

I've been creating Access databases on an occasional basis for about
12 years. I'm able to do most of what I need to do -- tables, forms,
queries, linking tables, creating subforms... I've had no experience
with creating runtime Access databases. I need to do that now. I'm
trying to understand how the whole runtime thing works.

Based on past experience with runtime programs from other
applications, I had believed:

-A runtime database is essentially a standalone file that contains all
components of the database as designed by the developer, plus enough
of the database engine to allow someone to use the database without
needing Access installed.

-This standalone file is all that need be distributed for the user to
use the database.

-The Developers toolkit, as purchased for earlier versions of Access,
or downloaded freely for A2007, would allow me to create this
standalone file.

-Having downloaded and installed the toolkit for A2007, it would be
relatively easy to figure out how to create this standalone file.

Can anyone help me understand the extent to which the above
assumptions are erroneous?

I would appreciate any help I could get in understanding how all this
works.

FWIW - The database that I want to distribute is relatively simple.
Currently it exists as a main table that contains all the data, and a
lookup table that is used to fill some of fields in the main table. I
may add a simple form at some point to allow users to see the data in
the table. The data will be entered to the database by syncing with a
PDA database where the data are originally collected. The system is
working (albeit not using a runtime Access database) with A2003. I've
created an A2007 version just by importing the A2003 version.

Thanks in advance,
-Scott

I've never created an A2K7 runtime, but I did run across the following
link:

http://msdn2.microsoft.com/en-us/library/bb501030.aspx

James A. Fortune
CD********@FortuneJames.com

[Tony Toews [MVP]]

SMcK <NP****@gmail.comwrote:

>Based on past experience with runtime programs from other
applications, I had believed:

-A runtime database is essentially a standalone file that contains all
components of the database as designed by the developer, plus enough
of the database engine to allow someone to use the database without
needing Access installed.

We'd call that the runtime package. And actually it's the same msaccess.exe as you
install on your system but with different registry keys making it a runtime system.

>-This standalone file is all that need be distributed for the user to
use the database.

-The Developers toolkit, as purchased for earlier versions of Access,
or downloaded freely for A2007, would allow me to create this
standalone file.

-Having downloaded and installed the toolkit for A2007, it would be
relatively easy to figure out how to create this standalone file.

Can anyone help me understand the extent to which the above
assumptions are erroneous?

Otherwise your fine. Also see Microsoft Access (Office) Developer Edition FAQ
http://www.granite.ab.ca/access/developereditionfaq.htm

>FWIW - The database that I want to distribute is relatively simple.
Currently it exists as a main table that contains all the data, and a
lookup table that is used to fill some of fields in the main table. I
may add a simple form at some point to allow users to see the data in
the table. The data will be entered to the database by syncing with a
PDA database where the data are originally collected. The system is
working (albeit not using a runtime Access database) with A2003. I've
created an A2007 version just by importing the A2003 version.

We'd also suggest splitting the database into a BE and a FE. This will make it muck
easier for the user to update their application when you distribute new bug fixes or
features. Even if it's only a single user database.

You want to split the MDB into a Front End MDB containing the queries, forms,
reports, macros and modules with just the tables and relationships in the Back End
MDB. The FE is copied to each network users computer. The FE MDB is linked to the
tables in the back end MDB which resides on a server. You make updates to the FE
MDB and distribute them to the users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page at
http://www.granite.ab.ca/access/splitapp/ for more info. See the Auto FE Updater
downloads page http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. The utility also supports Terminal Server/Citrix quite nicely.

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/

[SMcK]

On Sep 26, 9:08 pm, "Tony Toews [MVP]" <[e-mail]:

SMcK <[e-mail]:

We'd also suggest splitting the database into a BE and a FE. This will make it muck
easier for the user to update their application when you distribute new bug fixes or
features. Even if it's only a single user database.

You want to split the MDB into a Front End MDB containing the queries, forms,
reports, macros and modules with just the tables and relationships in the Back End
MDB. The FE is copied to each network users computer. The FE MDB is linked to the
tables in the back end MDB which resides on a server. You make updates to the FE
MDB and distribute them to the users, likely as an MDE.

In my case there's no server that all users are connected to. I'm
providing each user with a database program that is installed on a
PDA, and an Access database that sits on their desktop pc. That
database contains tables and relationships only (for the foreseeable
future). The PDA syncs to the desktop. We get the data when they log
in to a web site and send us a copy of the Access file. We have
programming at our end that takes the data and distributes it to non-
Access databases we already have established.

So in our case is there still an advantage in splitting the database?

-Scott

[Tony Toews [MVP]]

SMcK <NP****@gmail.comwrote:

>You want to split the MDB into a Front End MDB containing the queries, forms,
reports, macros and modules with just the tables and relationships in the Back End
MDB. The FE is copied to each network users computer. The FE MDB is linked to the
tables in the back end MDB which resides on a server. You make updates to the FE
MDB and distribute them to the users, likely as an MDE.

In my case there's no server that all users are connected to. I'm
providing each user with a database program that is installed on a
PDA, and an Access database that sits on their desktop pc. That
database contains tables and relationships only (for the foreseeable
future). The PDA syncs to the desktop. We get the data when they log
in to a web site and send us a copy of the Access file. We have
programming at our end that takes the data and distributes it to non-
Access databases we already have established.

So in our case is there still an advantage in splitting the database?

No, because you're using a different tool as the front end. And there's nothing to
split.

So you probably don't even need the runtime then. Windows XP comes with the Jet
DLLs. Or if you were to use ADO then the client systems would need to have MDAC
isntalled. But I'm not all familiar with MDAC.

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/

[SMcK]

On Sep 27, 3:35 pm, "Tony Toews [MVP]" <[e-mail]:

So you probably don't even need the runtime then. Windows XP comes with the Jet
DLLs. Or if you were to use ADO then the client systems would need to have MDAC
isntalled. But I'm not all familiar with MDAC.

Unfortunately I'm not familiar with ADO or MDAC, so I don't understand
these comments.

It sounds like you're saying that I could supply the Access database
to users with XP, and the Jet DLLs would work to allow syncing of the
PDA without Access needing to be installed. Yes?

I think, though, that I can't depend on my users having XP. The app
will be made available to law enforcement folks around the US who will
have a wide range of levels of abilities and computers. We have some
leeway in specifying how good their computers have to be, but I'm not
sure we can specify they have XP.

If I *could* rely on them having XP, would it be as simple as
providing them the mdb file and maybe the DLLs in case they don't have
them?

-Scott

[Tony Toews [MVP]]

SMcK <NP****@gmail.comwrote:

>It sounds like you're saying that I could supply the Access database
to users with XP, and the Jet DLLs would work to allow syncing of the
PDA without Access needing to be installed. Yes?

Correct.

>I think, though, that I can't depend on my users having XP. The app
will be made available to law enforcement folks around the US who will
have a wide range of levels of abilities and computers. We have some
leeway in specifying how good their computers have to be, but I'm not
sure we can specify they have XP.

Understandable.

>If I *could* rely on them having XP, would it be as simple as
providing them the mdb file

Correct. And you'll be fine with Windows 2000 too. (see below paragraph.) Windows
Vista should also have the Jet 4.0 DLLs but I don't have a Virtual PC session of it
immediately available to take a look.

I just ran a clean copy of Windows 2000 in a Virtual PC session. Clean meaning that
no Office or Access has ever been installed on it. Just an anti-virus program and
Microsoft Updates. Turns out it has a current version of msjet40.dll. So unless
you want to support Windows 98 or ME, which are horribly insecure and thus totally
inappropriate for law enforcement purposes you should be fine. Umm, I don't know
about NT 4.0.

>and maybe the DLLs in case they don't have them?

Well, I don't know if you can just ship DLLs. I rather doubt it.

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/

[AnandaSim]

On Oct 5, 12:45 pm, "Tony Toews [MVP]" <[e-mail]:

and maybe the DLLs in case they don't have them?

Well, I don't know if you can just ship DLLs. I rather doubt it.

FYI:

http://support.microsoft.com/kb/239114/
http://en.wikipedia.org/wiki/Microso...atabase_Engine

[Tony Toews [MVP]]

AnandaSim <An*******@gmail.comwrote:

>Well, I don't know if you can just ship DLLs. I rather doubt it.

FYI:

http://support.microsoft.com/kb/239114/

Good point. That would likely work. Although I'm not quite sure about a Win 9x
system that never had them in the first place. Still, that should install just fine.

>http://en.wikipedia.org/wiki/Microso...atabase_Engine

I never realized there was a Wiki article on Jet. Or if I did I'd forgotten.

Thanks, 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/