The difficult I do immediately, the impossible takes a little bit longer.
Design
Tips (Main)
Home
Naming Conventions
Where are the Options?
Options for Current Database
Object Designers
Trusted Locations
Repair (or Remove) MISSING or Broken References
Export Specifications
Import Specifications
Navigation Pane Options
Setting up a Model Database
Default Buttons and Legend
Set Subdatasheet to [NONE]
Creating a Settings Table
Not_In_List Event
Handling Attachments
Now, you are ready to build!  Start with the higher level tables, i.e. Customers, Orders, Purchase Orders, Employees.  Hmm, you might want to read My Database Standards first.  Then branch out from there keeping in mind who or what is attached to who or what.  For example, the Purchase Order table will need a Vendor ID field, th Orders Table will need a Customer ID field.

Once you've got all your Tables built feel free to post in any of the Forums found here and someone will be happy to assist with any qyestions you might have.
The first order of business when considering a database is to get out a pencil and some erasers, the eraser at the top might run out, and build a road map of WHAT you want to do!  For example record customer complaints, track orders with or without the purchasing of product, training - what type, what's needed for the job, safety or both.

Think it thru carefully writing down EVERYTHING that comes to mind.  It's easier to eliminate, much harder to include as you get further into the process.
Now that you have determined your needs it's a good diea to bring in all the people that are going to interact with the database.  I like to have a paper for everyone split in half.  One side is for what the database *Has to Have* and the other side for *Wish List* items.  (You can put a little note under Wish List items indicating those items may or may not end up in the final version.  This will save confusion later on.) After the meeting, review all the notes and, if needed, schedule a follow-up meeting.

These meetings are important as when Users have a vested interest in the database they are more receptive to the change that is comign their way once the database is released.
At this point you now need to identify, not create, all the Forms and Reports you will need.  Again, do not design them just identify them, i.e. for a Customer Complaint database you'll need Forms for the Customer's details and complaints previously filed, as well as, a one for logging the complaint.  You will also need a report showing the Customer complaints, especially for managment.  If you get stuck, you can always go back to the papers from the meeting.
Reading List
UtterAccess Newcomer's Reading List
Information and How To's on Database Splitting
Albert Kallal Splitting a access database, or how to run ms-access in a multi-user mode
Allen Browne Split your Access database into data and application
UtterAccess Sharing a Database
Tom Wickerath Implementing a Successful Multiuser Access/JET Application
And now we come to the *fun* part designing your Forms (and creating your queries).  However, before you take on Forms design you might want to create a few queries, like...

-qryCustomers
-qryEmployees
-qryVendors

Need some help with coding?  See the links here.

And now that you are all finished and reafy to distribute your database.  Don't forget to split it.  (Yes, I even recommend this for sinfle User databases.
Frontend Updaters and Version Control
Auto FE Updater
Update Database Frontends
Frontend Auto Update Enabling Tool
KenHigg Frontend Version Control
And to keep the Frontends up-to-date...
Designing a database is not an easy task.  Hopefully, the tips provided here will be of help.
This site uses cookies to collect data on usage. By continuing to browse this site you consent to this policy. Find out more here.