Not saving information I've entered

[Guest]

I built a form based on a table. I then added, in form design, several
unbound text boxes. When I enter information into those boxes, it does not
save the information, nor does it format as I have instructed. Do all the
fields of a form have to have a corresponding field in a table? If so, I was
told not to use combo list boxes in tables, but rather forms. Then I get a
type mismatch. What gives?

 

[Jeff Boyce]

Type mismatch occurs when, for example, you have a table field of type
Integer and you try to enter text values. Can you post the SQL statement
behind your combo boxes?

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Dirk Goldgar]

I built a form based on a table. I then added, in form design,
several unbound text boxes. When I enter information into those
boxes, it does not save the information, nor does it format as I have
instructed. Do all the fields of a form have to have a corresponding
field in a table? If so, I was told not to use combo list boxes in
tables, but rather forms. Then I get a type mismatch. What gives?

Unbound controls, by definition, aren't associated with any field in the
table or query the form is based on (its RecordSource), so their data is
not saved anywhere when the form is closed. That is, unless you write
code that saves it behind the scenes, that is. If you want the data to
be saved somewhere, you need to define fields in a table to save it in,
and then (usually) bind the controls on the form to those fields.

I can't tell what sort of problem you're having with the formatting.
You'll have to describe it more fully.

The same is true with the type mismatch -- you need to give more
information about the fields and controls you've actually set up, and
what action causes the error to be raised. But I can guess that maybe
you have set up a combo box that has only one column, the value to be
displayed, where it need to have two columns: the value to be displayed
and the value to be stored. Usually, the value to be stored is in a
hidden column; that is, one with a column width of 0. The combo box
wizard is pretty good at helping you set these up.

 

[Amy Blankenship]

You need to either bind the fields to the table or you need to have some
code that inserts the value of the unbound controls to the table fields. How
else would Access know what goes where?

Use the combobox wizard to help you insert a combobox properly until you get
used to making one from scratch. Press the magic wand button, then click
the combobox button, then click in your form.

HTH;

Amy

 

[Jeff L]

Do all the fields of a form have to have a corresponding field in a table?
Only if you expect to save your data in your table.

You can use combo boxes in your table if you want to. The thing you
have to make sure of is that the value you are saving is the same data
type as your field. You can't save a text value in a number field. In
most cases, the value you are saving will be an ID field (usually
numeric) that can be used to lookup the text value in another table.
The actual value that you are saving will be in the bound column of the
combo box. So if you have 2 columns (ID, Description) in your combo
box, and the bound column is set to 1, then the value in the ID field
is what will be saved to your table.

Hope that helps!

 

[BruceM]

Tables have fields. That's where data are stored. Forms have controls
(text boxes, combo boxes, labels, and anything else you can select from the
toolbox). Controls such as text boxes may be bound to fields in the form's
underlying table, or they can be unbound. If something is entered into a
bound control it is saved in the field to which the control is bound.
Something entered into an unbound control is not saved unless there is code
to write the information to a table field. Unbound controls are used for a
variety of reasons such as combining fields for display purposes, performing
calculations, finding particular records, and so forth.
What you were probably told about combo boxes was to avoid the use of lookup
fields in tables, for reasons that I won't get into here except to say that
they are somewhat technical (but no less important for that). Lookup
tables, such as a list of states or companies or whatever, are an entirely
different matter. These are used to good effect in databases everywhere,
and do not have the problems associated with lookup fields.
A type mismatch error could occur if you try to save text in a number field
or something of that sort. Without knowing more about how the error is
produced it is difficult to suggest a solution. It may have to do with
which column in your combo box row source you are trying to save, but that
is just a vague guess.
As for the formatting not being as you have set it up, more description is
needed.

 

[Guest]

Thanks, everybody, for your help. I will now go back to work and hopefully
get it right. Also, I do not have any experience writing code. where do I
find a primer?
--
Rich D
Armstrong Custom Homes
Redmond

Tables have fields. That's where data are stored. Forms have controls
(text boxes, combo boxes, labels, and anything else you can select from the
toolbox). Controls such as text boxes may be bound to fields in the form's
underlying table, or they can be unbound. If something is entered into a
bound control it is saved in the field to which the control is bound.
Something entered into an unbound control is not saved unless there is code
to write the information to a table field. Unbound controls are used for a
variety of reasons such as combining fields for display purposes, performing
calculations, finding particular records, and so forth.
What you were probably told about combo boxes was to avoid the use of lookup
fields in tables, for reasons that I won't get into here except to say that
they are somewhat technical (but no less important for that). Lookup
tables, such as a list of states or companies or whatever, are an entirely
different matter. These are used to good effect in databases everywhere,
and do not have the problems associated with lookup fields.
A type mismatch error could occur if you try to save text in a number field
or something of that sort. Without knowing more about how the error is
produced it is difficult to suggest a solution. It may have to do with
which column in your combo box row source you are trying to save, but that
is just a vague guess.
As for the formatting not being as you have set it up, more description is
needed.

 

[Dirk Goldgar]

Thanks, everybody, for your help. I will now go back to work and
hopefully get it right. Also, I do not have any experience writing
code. where do I find a primer?

I've heard good things about _Beginning Access <version> VBA_, by Smith
and Sussman, from Wrox. I'm sure if you search these forums for "Access
VBA books", you'll find other suggestions.

Don't think you have to write a lot of code to use Access effectively,
though. There's a lot of functionality built into Access, that all you
have to do is figure out how to use it. And the various wizards, though
they don't write very good code, do cover most of the basic things
you're likely to need. It's only when you want to extend your
database's functions beyond what's built in that you need to start
writing your own code.