MS-Access, is rather limited in its ability to do certain things, however to its credit you can do some things with it by using the wizards to design forms (the output from a query), desing queries (although i find that more confusing than writing the SQL manually) and you have tools (wizards) that can help you load, very slowly, record by record manually, the database.
Yes, you could write application code to interface with that, however, you don't have the time, dude.
This quickie plan will allow you to have a single user the one that the database is located on. And for heaven's sake, make back ups of all your work, even the data. ANd when it's 'production', make sure that they, or you, back up their data, on a regular basis, dude.
Don't code anything yet!!! (Now is the time to plan and understand your data) DESIGN FIRST BEFORE CODING OTHERWISE, YOU"LL BE CODING TO CORRECT A Y 10K problem.
I.Design the database, if it isn't already:
What elements do you need? (What fields of information) (One important thing to keep in mind: Arrays are NOT our friend in a relational database, so don't design them in put them in another table and have a key that ties the two tables together so that you can find the info between them when needed) This also means, no group occurs "X" number of times either, it's the same (bad) design.
II. associate these elements into their respective tables (and give these tables a short but meaningful name. Oh, don't put everything in a single table, depending on the number of elements, you may want several tables. PUt the data in their respective tables, ie. MEMBERS (only membership information, name, addresses, phone numbers, membership number, expiration of membership, etc.), FACILITY (name of facility, days that it's available (to make it simple, plan 7 pairs of time (open / close) one for each day of the week.), a key (to identify the facility- simple numeric is ok), location (address or other identifiers), telephone number, cost, etc., SCHEDULE (this table is the cross between the MEMBERS and FACILITY table), it will contain entries when a member schedules a facility, but only if the request is within the date/time when the facility is available.
Other issues to consider: What is the maximum number of users to a Facility at any given time? (that's a design consideration), Delete and reschedule, Blocking holidays, etc.
== review design with user ==
II. Determine what functions you want to provide and what reports and screens you want to have.
II a. Do all the functions and reports and screens have all the data elements in part I defined or are any missing? Then, put them in the right place.
== review with user ==
III. Use the MS-Access wizard to define the tables.
User proper data types (use 'date' for things that are dates, don't use char types in any realtional database
IV. Use the wizard to create the relationships and reports and screens.
== review with user ==
V. Load starting data into the tables.
VI. MAKE A BACK UP OF DATA AND DEFINITIONS.
== review with user ==
VII.
TEST and TRAIN USER
VIII. MAKE BACK UPs a regular thing.
Hope this helps.
Gary Joehlin
