Volunteer, Your requirements sound too complicated for just two tables. Study the database design materials that I sent earlier. The way you get information from Access is via Queries, Reports, and Forms. The way that I do it is to write a Query in SQL that has the information I need. Then create a Form and/or Report based on that Query. I use this approach since I know SQL well. I find the Access Query tool more complex than SQL itself. Of course before retrieving the data you need to input it. Each table or combination of tables need a maintenance form created. Sometimes, when the data is in another form, we load it into Access at first, one time. Then further Adds, Changes, or Deletes are done via Access Forms.
The development process is - Database design in Third Normal Form Queries in SQL that map the relationships (joins) Maintenance Forms (only simple equi-joins are maintainable Queries for retrieval Reporting Forms based on the Queries Reporting Reports based on the Queries (if you need the paper) Dick --- In ms_access@yahoogroups.com, "volunteerff8" <[EMAIL PROTECTED]> wrote: > > --- In ms_access@yahoogroups.com, "Richard Root" <d1ckroot@> wrote: > > > > Volunteer, > > I suppose you will be gathering and reporting on data from the > firemen > > (volunteers), Calls, Dispatch, Locations where they went, etc. > > These might be the entities about which you are gathering data. I > am > > assuming a Call is the "input" to the process. And, Dispatch is the > > output, the place where we record the information about the trip to > > the emergency. Each entity has attributes, for example the Call > > entity might have attributes like time, address, person calling, > > reported problem, etc. The Fireman entity might have attributes > like > > name, shift, phone number, special skill, etc. After listing out > the > > entities and their corresponding attributes describe the > relationships > > between the entities. A Location has zero to many Calls. A > Dispatch > > has 1 to many Firemen. A Call has zero to many Dispatches. Etc. etc. > > > > See the following which is a database design for a fire > department - - > > http://ocw.mit.edu/NR/rdonlyres/Urban-Studies-and-Planning/11- > 521Spatial-Database-Management-and-Advanced-Geographic-Information- > SystemsSpring2003/6873A2CD-0C0B-41DF-86D1-D9713DF0BB8C/0/lect7b.pdf > > and more generally - - > > http://en.wikipedia.org/wiki/Entity-Relationship_diagram_(ERD) > > > http://www.infocom.cqu.edu.au/Courses/spr2000/95169/Extra_Examples/ERD > .htm > > http://www.getahead-direct.com/gwentrel.htm > > > > Dick > > > > > > --- In ms_access@yahoogroups.com, "volunteerff8" <volunteerff8@> > wrote: > > > > > > is this any one here that could help me build a data base for m y > fire > > > department. I have started it put not sure if I am doing it right > new > > > at this. I first built a table and name it memebers to list all > > > memebers then I built a table for calla. this for all call to be > listed > > > that we run in amy given day. I would to pull information for > this to > > > tell me how many calls we run in a month also to tell me how many > call > > > each memeber has run. Help > > > > I looked and what you wrote again you hit it on the head. I am just > not sure how to pull the information out of the data base. Many be I > need more talbs, did I make it to big with just two talbs > > Dave >
