I am currently putting together a database to analyse some date and currently
havein a form; 2 combo boxes with a 'Text' type; 3 combo boxes with a
'Yes/No' type; and the last i would like to be able to retrieve a search of
e.g. 50 people to 250 people.
And then for all this data to be pulled from the main table and put into a
temporary table/form, which i can then look at,
I have looked at doing this a number of different ways, but nothing seems to
work, anyone got any ideas?
Cheers
Well... you're mixing apples and oranges here.
Tables store data. Forms are windows which can be used to display or
edit data stored in Tables. It sounds like you've made the (very
common) error of starting with a Form and then back-designing a table
to fit the data.
Similarly, a combo box is a data editing and display tool, not a
datatype. You don't store a combo box in a table - you USE a combo box
as a method of storing data (a number -1 or 0 for a Yes/No field,
text, or a numeric ID) into a table.
Thirdly, you are making another common error by assuming that you need
to put data into a temporary table in order to look at it. You don't:
that's what Queries are for!
The place to start is by turning off your computer, leaving the room,
and scrounging around for a pencil (with a good eraser, if you're like
me <g>) and a pad of paper. Identify what kinds of Entities -
real-life people, things, or events - are of importance to your
application (people, obviously, but I cannot tell what else from your
post). Each kind of Entity will have its own table - e.g. a People
table might have fields PersonID (a unique primary key, names are NOT
suitable since they are neither unique nor stable), LastName,
FirstName, and other biographical data; you might have "lookup tables"
for commonly used values for your combo boxes, though I'd advise
AGAINST ever using Microsoft's misleading and misdesigned "lookup
field" type; you'll have other tables as well.
You then need to identify how your tables are related: one to one
(very rare and at this stage probably a mistake); one to many
(universal); many to many - which requires yet another table, a
"resolver table" to record the relationship.
Once you have the table structure designed, THEN start thinking about
Forms and Subforms to enter data into the tables.
You can - and will - base a Form on a Query, or use the Filter by Form
utility on a Form, to selectively display data about some particular
person or subset of people.
Post back with a more detailed description of your data if you want
more help!
John W. Vinson[MVP]
