After MDE - how see data?

[Guest]

I need help before I convert to MDE. THANK YOU in advance!

Here are the pieces I have created:

1) Input form for user to enter data
2) MainTable linked to Input form - where the data is compiled
3) MenuOptionsTable that supplies drop down options to the form
4) PrintForm - a form linked to a print command on the Input form
4) MainScreen - looks like a switchboard - user starts from here.

My 3 MAIN QUESTIONS:

Which pieces do I convert to MDE?

How do I then have access to data the user has compiled in MainTable?

If we need to make changes to any of the pieces - I know I should make these
on my origninal MDB file, and then turn the new version into MDE, but how do
I then incorporate all the data that might have already been entered by the
user?

Thanks!

 

[Larry Linson]

You split the Tables (with data) and Relationships into a separate MDB,
which you leave as an MDB (for the "back-end", which can be shared between
multiple users by placing it in a shared folder).

You link the Tables from the remaining MDB, which contains Queries, Forms,
Reports, Macros, and Modules, and perhaps local lookup Tables. It is this
that convert to MDE for the "front-end" but maintain the MDB copy for
development -- you will not be able to use the MDE for development. If you
have multiple users of the same data, you give each user their own copy of
the front-end MDE.

Most often, your changes / corrections will only be to the front-end, so you
make them, generate a new MDE and let the users install it in place of the
old one they've been using. MVP Tony Toews has an Auto FE Updater at his
site, http://www.granite.ab.ca/accsmstr.htm, or you can read my article on
versioning at http://accdevel.tripod.com for a less-automated approach, both
useful primarily if you have a multiuser application.

Larry Linson
Microsoft Access MVP

 

[Guest]

Hi Stilla,

Which pieces do I convert to MDE?

You do not convert pieces to an MDE file. You convert .MDB files into .MDE.

If we need to make changes to any of the pieces - I know I should make these
on my origninal MDB file, and then turn the new version into MDE, but how do
I then incorporate all the data that might have already been entered by the
user?

Split the database into two databases: a front-end (FE) and a back-end (BE)
databases. Convert the FE database to the .MDE file after you are done with
your development work. There is no benefit to converting the BE .MDB file.
For more information on splitting a database, please see the links available
here:

http://home.bendbroadband.com/conradsystems/accessjunkie/splitting.html

How do I then have access to data the user has compiled in MainTable?

I don't understand this question...

If this is a multiuser Access application, then I suggest implementing the
suggestions shown here:

Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[Guest]

Thank you Tom for your careful and thorough reply.

I should have clarified...I'm doing this for one (person) client - I will be
sending her the whole file via email, and we have no capacity for file
sharing.

We may want to make some changes in the form in the next couple of months,
but during that time, she will have already collected data from the form.

Are you saying that I can convert everything to MDE execpt the "Main Data
Table" (where new data from the form is being collected)?

In that case, when she sends me back the file, I can transfer this main data
table into my MDB file, make the changes on the form, RE-convert into MDE,
and send it back...?

I know it's a bit primitive, but given we're not on the same network, should
this work?

Thanks in advance

 

[Guest]

Hi Stilla,

I should have clarified...I'm doing this for one (person) client - I will be
sending her the whole file via email, ...

That's fine. You should still split the database into two databases: a
front-end (FE) .mdb file and a back-end (BE) .mdb file. This way, she will
not need to send you anything, *unless* you need to make a change to the BE
(data) .mdb file. If your updates are restricted to new or modified queries,
forms, reports, macros or modules, then you only need to send her a new copy
of your FE database each time you are ready for her to try it out. It will be
helpful if you make any and all changes possible to the BE database first,
before splitting it and sending it to her. You should also ensure that you
have the following changes in place:

Disable NameAutocorrect
Set all table SubDatasheets to [None] and
Ensure that you have a persistent connection to the BE database

It is also helpful to have some code in your FE database that automatically
fixes linked tables, so that your user does not have to use the linked table
manager each time they receive an updated version of your FE database. If you
are not sure how to do this, then a temporary solution would be to ensure
that both you and your client have the BE database in exactly the same path.
There is code available on the MVPS web site for fixing linked paths
on-the-fly:

http://www.mvps.org/access/tables/tbl0009.htm

Are you saying that I can convert everything to MDE execpt the "Main Data
Table" (where new data from the form is being collected)?

I'm sorry, but I'm still not understanding your question. Data is stored in
tables, not forms. You convert the FE .mdb file to the .mde format. Since you
are in developement mode right now, perhaps you should not worry about
converting to .mde format with each release of your FE database, unless you
are trying to protect any code from being viewed by your customer, or design
changes to forms, reports or modules.

In that case, when she sends me back the file, ...

The only reason she should need to send anything back to you, would be if
you need to make a change to the BE (back-end) .mdb file. This includes such
things as adding or deleting indexes, fields or tables. A possible
alternative, if your customer can follow simple instructions, it to have her
make any changes to the BE database that you tell her to make via written
instructions.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________