See below
By this are you saying, "Why are you using code instead of just
letting the user do the data entry?"
Or are you saying "Why are you using
'irst_studenttracking!Exclusion = true" instead of 'chkExclusion
= true?"
Maybe, maybe not, though the latter should be:
(Me!chkExclusion) = True
....or...
(Me.chkExclusion) = True
The parens are crucial to force evaluation, and the parent object is
necessary to disambiguate (rather than depending on VBA to do it for
you).
Surely you can think of lots of situations where columns need to
be populated, but not seen by the user. Are you saying to make an
invisible control for every column in the table you need to
populate?
No, I'm not saying anything of the sort. The field's in the form's
recordsource are available for editing even if they are not used in
the controlsource of a control on the form.
For instance, I usually don't display the PK to the user, but this:
MsgBox Me!PersonID
....is still going to work, assuming PersonID is a field in the
form's recordsource.
All those fields are available for editing directly by just
referring to them the same way I've referred to PersonID.
The fact that you don't know this shows that you somewhere along the
line you skipped learning the most basic aspects of how Access
works. I don't mean that statement as any kind of value judgement,
just as a statement of fact -- and it's causing you problems because
you're making things way, way to hard for yourself.
The key point:
The default collection of a bound form or report is the union of the
Fields collection and the Controls collection.
Thus, chkExclusion might be bound to a field named Exclusion, but
Me!chkExclusion and Me!Exclusion will both allow you to edit the
underlying value, the first indirectly via the control, the second
directly (which will be immediately reflected in any control to
which it's bound).
And you can work with the value of Me!Exclusion in code and edit it
even if it's not bound to a control (in reports, things are
different, in that you can't reliably refer to a field in the
report's recordsource unless it's bound to a control; this is
something that did not used to be the case, and is, in my opinion, a
bug; but it's been that way for several versions now, so likely not
something that's going to be fixed).