Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Setup / Configuration / January 2004

Tip: Looking for answers? Try searching our database.

What is the value of using a Front End and a Back End ?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Ann Checkley - 30 Jan 2004 16:26 GMT
I inherited a database, partially designed in 1999 by
someone with far more knowledge of ACCESS than me. I would
like to learn a few things about the logic used in the
design, as I try to simplify it for our use. He created a
Front End, which contains all the forms and queries, and a
Back End, which contains 98% of tables. I just want to
understand the purpose/benefit of doing it this way.
Thank you for your time.
Ann
Bruce M. Thompson - 30 Jan 2004 17:46 GMT
> I inherited a database, partially designed in 1999 by
> someone with far more knowledge of ACCESS than me. I would
[quoted text clipped - 3 lines]
> Back End, which contains 98% of tables. I just want to
> understand the purpose/benefit of doing it this way.

See the following page at Tony Toews' web site for an explanation of some of the
benefits:

Splitting your Microsoft Access MDB into a front end and back end
http://www.granite.ab.ca/access/splitapp.htm

Signature

Bruce M. Thompson, Microsoft Access MVP
bthmpson@mvps.org (See the Access FAQ at http://www.mvps.org/access)

>> NO Email Please. Keep all communications
    within the newsgroups so that all might benefit.<<
Ann Checkley - 30 Jan 2004 21:55 GMT
I appreciate the reference to Tony Toews' explanation. I
read it thoroughly and am left with the thought that this
configuration is best left to those who actually write
code and develop massive databases.
Thank you.

>-----Original Message-----
>> I inherited a database, partially designed in 1999 by
[quoted text clipped - 15 lines]
>
>.
Paul Overway - 30 Jan 2004 22:09 GMT
It is good advice...even for a novice.  Databases usually grow in complexity
over time.  So, the sooner you split it, the better.  It really is a pain to
get everyone out of a database when you need to make changes.  Plus the
potential for corruption is very real and you'll be sorry if it happens.
--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

> I appreciate the reference to Tony Toews' explanation. I
> read it thoroughly and am left with the thought that this
[quoted text clipped - 30 lines]
> >
> >.
Bruce M. Thompson - 30 Jan 2004 23:37 GMT
> I appreciate the reference to Tony Toews' explanation. I
> read it thoroughly and am left with the thought that this
> configuration is best left to those who actually write
> code and develop massive databases.

It is best for those who make changes to their application (be it occasional or
frequent changes) and, especially, for those who use their database in a
multi-user environment (I *always* split every database I create unless it is
only a temporary file for testing purposes). The size of the database really has
no bearing on such a decision - only the value of your data does.

:-)
Signature

Bruce M. Thompson, Microsoft Access MVP
bthmpson@mvps.org (See the Access FAQ at http://www.mvps.org/access)

>> NO Email Please. Keep all communications
    within the newsgroups so that all might benefit.<<
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.