Runtime For Dummies

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

>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?

>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.

SMcK <NPi...@gmail.comwrote:

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?

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.

>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?

>
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