Re: How did you complete this?

Hi Tina, Thanks very much for the advice. I definitely need to get a good
grasp of the fundamentals of dbase design to ultimately save time by getting
things right earlier, rather than having to redesign every time I learn a bit
more! I'll check that link out. You're right about linking the field trip
sightings and the various lists, and that as you say will warrant some
serious jigging. I also think I need to create the ability to short-circuit
the above process of adding to the list via observation records by also
creating a direct entry option; people who have been birdwatching for years
may have forgotten the details of where they saw a bird for the first time,
so perhaps forcing to them to create a new observation record in order to
populate a list (which could be hundreds - more if you include
plants/butterflies and mammals) might be forcing them a bit - but we'll see -
as you say I need to have a good think about the mechanics of it all - and
yes, it is quite good fun, especially when bits of it start to work!!

Again, many many thanks for your trouble. I may update you if that's OK
later on...

tina wrote:
hmm, okay. your explanation was helpful. where i think you're getting
confused is the difference between recording data and extracting information
from it.

So basically, the DB is to Record observation details (could be easily
adapted to other hobbies, trainspotting, fishing etc) but I also want to have
the facility to record lists of species seen.

you don't need to record "lists". what you need to do is identify what data
must be recorded about an instance of a species sighting, in order to
include that instance (record) in a defined list (report).

This is what birdwatchers tend
to do (and plane, train, eddie stobart spotters do too, I imagine) - keep
separate lists of things seen: "How many birds have I seen: Ever; This Year;
Last Year; Whatever year; In my back garden; In my local park, In a
particular county/Country etc etc"

you've already begun to define your data needs. for example: if you record
the species and date and time of each sighting, then you can query the
records for a list of

species = bird
time frame = this year (or last year, or a specific year, or all years,
etc.)

if you also record where each sighting occurred - i would probably recommend
a table of locations that each user can enter records into, so each user's
database has a locations list that is relevant to him/her - then you can
query the records for, as another example, a list of

number of each species, sighted at each location, in a given time frame

include location specifics *in the locations table*; for example if one
location record just says "my local park", that's fine - but include fields
in the location table for county, state, country, etc, so each location is
fully defined. that way you can query for "my local park" sightings, or for
all sightings in France (if French locations are on your locations list) -
which may include your local park, if you live in France.

hopefully the above makes some sense to you. what you're attempting sounds
like a lot of fun to set up, actually - a challenge to thoroughly analyze
the process and design a tables/relationships structure that will support it
and allow for planned expansion in targeted areas. i really recommend that
you read up on relational design principles; Access is a fiend at extracting
valuable information out of just this kind of minute detail data - *if* you
leverage the power of the software by implementing good design. i believe
that process analysis is going to be key to your success, so i suggest you
check out the tip at http://home.att.net/~california.db/tips.html#aTip1. the
book mentioned there provides good instruction on process analysis as well
as relational design principles.

hth

Many thanks for taking the trouble to reply, Tina. Yes, I seem to have sort
of barged in on an existing thread, I originally asked the original poster if
[quoted text clipped - 83 lines]
Creating a new table for every subset of the data just clutters your database
with tables of forgotten meaning, bloats your database and ruins performance.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/200809/1

.