General Question about Froms

D

D Dawson

I want to create a database to record details from condition surveys.

I would like the front end to be a form with location, date, and elements 1
to 16 (structure, roof, fabric etc.)

Is it possible to create a form that will input into several rows of my
main table i.e. to capture the elements 1 to 16 and also the general fields
like location and date.

Much obliged
D Dawson
 
L

Larry Daugherty

If those additional 16 elements are each different attributes of the
unique entity that the form seems to be about then they should each
occupy a field in the single record for the entity.

You have two issues: Data design and Form design.

For data design see microsoft.public.access.tablesdesign. For Form
design see microsoft.public.access.forms Another good newsgroup is
microsoft.public.access.gettingstarted

You may have a lot of information to address on a single form. There
are techniques that can help such as organizing your form into pages
(fairly simple) or using TAB controls (not so simple but highly
effective).

HTH
 
D

D Dawson

Each of the building elements have the exact same fields: condition-category,
repair cost, and priority.

I have created a separate tables containing the data for these fields.

My present form lets me select the element and input the data for that
element. the problem is that I would like to have 16 fields on my form and
for this to input 16 entries into my table. rather than have the user select
which element they are writing about.


Larry Daugherty said:
If those additional 16 elements are each different attributes of the
unique entity that the form seems to be about then they should each
occupy a field in the single record for the entity.
Click to expand...

They are different attributes of the same entity and I have set them up on a
single field, which records the attribute reference number from a separate
table. I have common fields for:
condition reference (A to D)
Repair cost (£/p)
Priority (1-4)
for each element

I am taking this design from a paper copy of a table where the headings are:

Location, Date:
Elements, Condition (A-D), Repair Cost, Remaining Life, Priority (1-4)
You have two issues: Data design and Form design.
Click to expand...

My present form is set up to the record the data regarding one attribute at
a time, rather than have separate fields for each element and duplication of
condition, cost and priority along each.
 
L

Larry Daugherty

I'm getting confused! It seemed one way, now it seems another ..
maybe!

Forget trying to mimic a paper form. The important thing is the data
and to understand the data you have to identify the entities in play
and the relationships between them.

Those repeating elements you reference in your last post make me
believe that you already have the correct data design and the correct
form design.

I'm getting the idea that your only objection is the need to indicate
which element you are addressing. If, and only if, you will always
report exactly those same 16 records and no more than that per
structure then you could create the child records when you create the
parent record. Be advised, it goes against the grain to create an
empty record. There is never a need for an empty record. If you
don't absolutely, positively know that there will be data in a record
it shouldn't be created.

To do it, In broad strokes: Capture the Primary key value of the
parent record. Open a recordset on the child table and, using
..AddNew, copy the PK into the child record FK, Enter the Element name.
..Update. Loop through all 16 elements. Refresh the recordset. Close

HTH
 
L

Larry Daugherty

Long past my bedtime....

You probably have established Referential Integrity in that
relationship so you don't need to bother with the PK value, it's done
for you.

HTH
 
Top