Here are some links to Access tutorials and so forth. A better understanding
of relational database principles will be a big help, I think:

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/acc...resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

Roger Carlson's tutorials, samples and tips:
http://www.rogersaccesslibrary.com/

A free tutorial written by Crystal:
http://allenbrowne.com/casu-22.html

A video how-to series by Crystal:
http://www.YouTube.com/user/LearnAccessByCrystal

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials


IMHO Crystal's tutorial is as good a place as any to get started.

To sum up a point Tom made, field names are not the place to store data such
as "bed". I think you understand the point, but a summary explanation can't
hurt.

I don't think there is a need to move the data once the item has been picked
up. Just add a field to the Donations table to show the pickup date, or
otherwise to indicate the item has in fact been picked up (rather than simply
scheduled to be picked up). To get a list of items that have not been picked
up yet, use a query based on the table to find all records in which
PickUpDate is Null, or PickedUp is Yes, or whatever exactly works for you.

To find donations by a person, or donations within a date range, or whatever
you need, build a query or devise a filter to select the desired records only.
The point for now is not to provide the details of how to go about that, but
rather to point out that if a table contains all the necessary information
about an entity (such as Items or Donor), you can refine the group of records
you wish to see. If you have a field for the Donor and another for the
DonationDate, you can find out what that person has donated in any time frame
you choose.


awsmitty wrote:
John,

The items are just what we pick up, not deliver; the list is only to give
the drivers and the dispatchers on idea of how big the loads are getting for
that day. These trucks do 6-10 pickups per day. It turns out to be several
loads per day, per truck. I don't think I would ever be searching the items,
maybe, but I'm not planning on it. The only searching is to get the grid
from the address. So, yes, I'm wondering if these other tables tblItems,
etc, all of them really, need to be linked. I mentioned this in my first
post. I really truly don't know. The way I see it, and I could be wrong,
what’s needed is some temporary storage place, temporary – from the time the
donation is called in to the time we pick it up, could be a few days, might
be several months (honestly, some churches schedule months in advance to make
sure we are there). Once the ticket is printed, at that point the whole
ticket with all of its information, goes to some table to be stored
indefinitely (I hear 7 years, for IRS purposes, but I really don’t know).
Now that table may need to be searchable. John makes a donation, files his
taxes, but two years later the IRS comes along and questions it. In the
meantime John has lost his receipt. John, or for that matter the IRS might
come to us to verify that John donated all this stuff. I can find John
easily enough, just give me his address and I’ll use the same routine as when
I found him the first time. I assume what Tom was trying to do, and what I’m
interested in doing just as an educational exersize, is to manage the data
efficiently and conveniently, and learn a little along the way. I assume
Tom’s method would be more efficient. Convenient, well, for you guys that
know this forwards and backward, maybe so, but for me, I have to really keep
my eye on the ball or I’ll loose track of what’s gong on. But, it could
prove to be interesting.

First, the overall objective. A few others and I work in a dispatch office
in a homeless shelter. (I will just be upfront about it.) We are
[quoted text clipped - 58 lines]
I will try next time not to be so wordy, it's just that I need to remove
this from my head and put it into yours, as accurately as possible.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/201001/1