Checkbox remains checked

[SoNew]

I am trying to add a checkbox to a form and am having a rather basic problem. As you will quickly tell I am not an access person, but my boss seems to think so :)
Anyhow, I needed to add a field but couldn't add it to the original table as it is linked. So I created a new table just for the sake of tracking the data. (called Mentor). I created a primary key auto number (ingMentorID), the checkbox info (blnMentor) and (ReadingCoachID) which is what a link to on the relationships page with the main table (going with relationship all Reading Coach, and Mentor where data is the same).
So then on the main form I added a checkbox. I told it use control source blnMentor but in order to do so I had to change to property setting of the mainform to have the record source be tblMentor (otherwise blnmentor wasn't an option and the checkbox was always gray).
So now when I check the box on one student's record, indicating they are a mentor, it checks it on every student's record...or vice versa if I uncheck it. This is a problem.
I read the the archives and found an article about check boxes that stayed checked and it said to check the control source for the unbound item...control source is blnMentor.
What am I doing wrong here?
Any ideas would be great...and if they could be in simple minded human language I would greatly appreciate :)
SoNew

[Stewart Ross]

Hi. Your checkbox is unbound - that is the only explanation for the repeating of the same state down all rows. So although it appears that it is bound to an underlying field the evidence is that it is not. Please check whether or not you really have the correct field name in your control source property - it should appear in the drop down list for that property.

If your form is bound to a query and not the table itself, have you included that field in your query?

In any case, the only explanation that comes to mind for the behaviour is that the control is unbound. In a continuous form or a datasheet view there is really just one single instance of the set of controls, repeated for all rows shown on the screen. That is the main reason why an unbound control's value repeats down all rows on the screen, and ripple changes for all rows at once if you change its value.

-Stewart

[SoNew]

How do I know if it is bound to a query (I didn't create the original form) - I went to properties under the form and the record source field was blank (I had to put in the tblMentor to have a drop down list on the blnMentor button) - but originally it was blank.
Thoughts?

[Stewart Ross]

Hi. An unbound form - one with no specified recordsource - is not normally used for table-level data entry/editing unless it is bound at run-time by code setting the recordsource to an SQL statement or a query of some kind. The disadvantage of this approach is that it is impossible to tell from an unbound form which code module is doing the run-time binding.

Excepting unbound forms used to filter bound forms within them, or switchboard type forms, unbound forms are a bit of a contradiction in terms. Can't do anything useful unless bound, really, so binding by VBA code called from an event on a form, say, is the norm here.

-Stewart