Basic question on creating easier-to-update databases

  • Thread starter Thread starter Dave R.
  • Start date Start date
D

Dave R.

Hello,

I am working on a project where we have given 7 clients databases for them
to enter data in. Periodically, we find issues with our database here at
homebase, that need to be changed at the 7 client sites.

At this point, I am calling people to walk them through making the change.

Is there a better way to design the next database, where I could send some
small file to make the change, and it would keep their data intact, yet make
the change?

Or can one write a program to open the database, make the changes, save
them, and exit?
 
If your db is properly split into front-end and back-end, you can simply
send them a new front-end whenn changes occur (assuming they have not made
their own modifications). Back-end is quite a bit more difficult, and I
will leave it to the pther posters here to make a recommendation for a best
practice/

--
Kevin Hill
President
3NF Consulting

www.3nf-inc.com/NewsGroups.htm
www.DallasDBAs.com/forum - new DB forum for Dallas/Ft. Worth area DBAs.
 
Is there some good reading on what constitutes a front end or a back end?

I'm sorry I wasn't very detailed in my opening message. Some things we need
to change are query criteria and wording on forms.

Thanks
 
Dave R. said:
Is there some good reading on what constitutes a front end or a back end?
Click to expand...

You want to split the MDB into a front end containing the queries,
forms, reports, macros and modules with just the tables and
relationships. 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
I'm sorry I wasn't very detailed in my opening message. Some things we need
to change are query criteria and wording on forms.
Click to expand...

Excellent reasons, among many, for having a split system.

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
 
Back
Top