Not a bad idea as long as you establish controls on it, physical or systemic. Basically, you set up a form that doesn't allow any access besides the current student, and that requires a password or other non-obvious action to change. Then you sit the person in front of that one form.
Hmmm. I'd just make a separate front-end that links to your database and has only the minimum forms necessary for whatever they are entering. That way, there isn't any sensitive data to be looked at. You might even link it to an "input' table in the backend, where you can review the records before allowing them to be moved to the real table. Your choice. Don't build the Sistine Chapel when you really need a bungalow.
About Years - Remember, your database can have many years in it without those being reasonable choices for a current student. A doctoral student will need 5-6 years out, but most of your students only need the next few years. So, for that form, you could use it as I described above, with a calculated limit on years - current year to year + 5 or something.
Code:
SELECT TT.Term_code, TT.Term_Year & " " & TS.SeasonName
FROM tblTerms AS TT
INNER JOIN tblSeasons AS TS
ON TT.SeasonID = TS.SeasonID
WHERE TT.Term_Year BETWEEN (Year(Date) - 1) AND (Year(Date) + 5);
Not sure whether there should be some & around the Year terms.
The SQL could also be modified by other controls on the form. You could put in a text box where they can enter the year, and have the AfterUpdate event of the text box set the SQL for the combo box. That's the general concept. Doesn't much matter if it's a checkbox that says "include all years" or a text box for some other bell or whistle.
If you have two or more controls that are changing the SQL, then I highly recommend coding a procedure to set up the SQL, and have it read the various controls to figure out what kind of SQL to build. This way, each control can call the same procedure and the resulting SQL will be correct.