Form View is Blank

[Guest]

Hi,

I have designed a form in Design View and everything seems okay. Then when I
move to Form View, NOTHING appears except the background colors, no field
boxes etc.

Any thoughts?

Thanks

 

[Rick Brandt]

Hi,

I have designed a form in Design View and everything seems okay. Then
when I move to Form View, NOTHING appears except the background
colors, no field boxes etc.

Any thoughts?

Thanks

That is normal for a form that has no existing records and does not allow new
ones.

 

[Van T. Dinh]

Open the DatasheetView of the Query by itselft and check:

1. Any rows returned?
2. Data can be edited through the Datasheet?
3. "New Record" row in the Datasheet?

If no rows is returned, the problem is in the Query. If there are rows
returned, there may be wrong settings on your Form.

The data manipulation on the Form depends very much on the RecordSource
Query. Answers to Q2 & Q3 will tell you whether the data can be edited /
entered via the Form.

For example if the Query is non-updatable and returns no rows, your Form
will behave exactly as you described.

 

[Rick Brandt]

Hi Rick,

I have now put records in the tables and still NOTHING in the form
view. How do I set it up so that the the field boxes appear in the
FORM view and that it can be used to input records.

This works when I build the form using fields from one table only.
But with this form that uses a query that includes fields from
several tables nothing appears.

Look at the output of the query separately (not using the form). Most likely
the joins in the query cause it to produce zero rows of output. In addition,
queries against multiple tables are usually not editable. The more tables you
add the less likely that editing will be allowed.

So, as stated you have a query with no current records and no ability to add new
ones. A form bound to such a query will behave exactly as you describe.

Again what I want my users to be able to do is to enter, edit and
view data but at this point the form view has NOTHING but color in
the background, no field boxes or anything.

Combining all tables into one big honking query can be a good solution for
analysis and/or reporting, but not for entering/editing data. Try a form with
one or more subforms, each bound to ONE table.

 

[Guest]

I am confused. Wouldn't binding everything into ONE table go against the
point of Normalization? I have 5 different tables that I am working with. One
main table and the others which are linked through a One to Many
Relationships.

What would be the best way for me to design a form that allows data
entry/editing for fields from several different tables?

Thanks.

Pat L.

 

[C.Evans]

I think what Rick means, is that if you have a single table which contains
all the "one" parts of your table relationships, and all the others are the
"many" parts, then you can create a single form based on the first table,
and have four subforms in that first form would allow editing of the other
four tables.

I personally would use unbound forms in this circumstance, but that would
involve quite a bit more coding, so it may not be appropriate here.

HTH

 

[Grover Park George]

This is the real beauty of a data aware program like Access. Forms and
subforms are designed specifically to take advantage of the relationships
between master and child tables (one to many).

If you've enforced referential integruty, and you definitely should do so,
you must enter records in the table on the "one" side of the relationship
before you can enter any records into the table(s) on the "many" side. And
the main form with sub form design helps you do exactly that: you enter
records into the main form first, then into one or more subforms.

In fact, there is a pair of properties associated with the subform control
which makes this very straightforward. It's called "Link Master Field/Link
Child Field". You select the two keys (primary and foreign) which link the
two tables, and from then on the forms coordinate the recordsets in the two
forms.