Forums
New posts
Search forums
Members
Current visitors
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Forums
Archive
Newsgroup Archive
Access Newsgroups
Access Table Design
Separate database for tables?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
Reply to thread
Message
[QUOTE="Cheryl Fischer, post: 2547443"] Holly, If you run a single, monolithic database application (one where the tables are in the same database as forms,queries, reports, etc.): - You will need to have all your users exit/close the database anytime you want to make a design change to a form, report, query or macro. Users will not like this, nor will you. If you split the application and keep all of your queries, forms, reports, macros and modules in their own MDB file, you can make changes to your heart's content in your own copy of the front-end MDB and deploy changes to users by simply having them copy the new MDB file over their current copy. - More important, if you are using an unsplit database where all users are opening/running the same copy of the database, you are asking for and are practically guaranteed to have database corruption problems! Generally, the steps to set up a multi-user, split application are as follows: 1. If you have not already done so, split the application into a Front-End and a Back-End. The Database Splitter utility found at Tools|Database Utilities|Database Splitter is one way to do this. The Front-End (FE) will contain all Queries, Forms, Reports, Modules, Macros and local-use tables. The Back-End (BE) will contain all tables to be shared among users. 2. The BE will reside in a folder on your server, where full permissions for each user will be granted (Read, Write, Create, Delete, Execute). 3. In the FE, Link to the tables in the BE. To avoid problems with changing drive mappings, link to the BE tables using the full UNC, starting with My Network Places and drilling down through folders until the actual database name of the BE is found. 4. An individual copy of each FE will reside on each user's computer. For ease of distributing updates to FEs, see: [URL]http://www.granite.ab.ca/access/autofe.htm[/URL] which describes an AutoUpdater for front-ends, developed by Access MVP Tony Toews. 5. Additionally, a copy of the most current FE in use by users should be kept on the server. You will do your maintenance/update programming on your own copy of the FE on your own computer. When updates are ready to be distributed, you'll copy your modified FE to replace the one on the server. Those are pretty much the high points. [/QUOTE]
Verification
Post reply
Forums
Archive
Newsgroup Archive
Access Newsgroups
Access Table Design
Separate database for tables?
Top