I see a number of basic design issues with the structure of your database, but first to explore the specific issue:
Are these fields of type calculation or are they number or text fields with an auto-entered caculation? Auto-entered calculations that refer to fields in other records or tables will not automatically update when the data in that referenced field is modified, nor do they assign values to existing records when newly added to your table. (You have to use something like Replace Field Contents with the same calculation expression to update your existing records.) Use fields of type calculation with these expressions instead.
Now the design issues.
In the StudentSpecialProgram table I have a field for each program possible to indicate if the student takes place in that program.
That sounds like a really challenging way to set this up. Here's an alternative that can be a much simpler and much more flexible:
Use this combination of tables and relationships to document the enrollment of your students in your special programs:
Students::StudentID = SpecialProgram_Enrollment::StudentID
SpecialPrograms::ProgramID = SpecialProgram_Enrollment::ProgramID
SpecialPrograms is where you document each existing program. In your case this will be "over 20" such records. The SepcialProgram_Enrollment table is a "join" table that makes the many to many relationships need so that one student can be enrolled in more than one program and each program can enroll more than one student.
On a Students layout, a portal to SpecialProgram_Enrollment can be used to list and assign SpecialPrograms to that student. On a SpecialPrograms layout, a portal to SpecialProgram_Enrollment can be used to list and assign students to that Special Program.
This reduces your many different programs in dedicated fields to a flexible set of join table records so that adding a new program is a simple as adding one new record in SpecialPrograms, then using the join table to list the enrolled students.
Thank you, this is a lot cleaner set up and my 1-1 relationship must be throwing this off? I'm unclear about one thing though (which I didn't include detail about originally) - I need to be able to indicate if a student was in the special program during a specific time frame (in the SpecialProgramEnrollment table I have ProgramEntryDate and ProgramExitDate). For example, I may need to compare many other data sets (within the same DB) like absences, GPA, suspensions, etc for a specific time frame that the student was in a program, and I may need to go back historically as well which is why I had created calculation fields to 'flag' the student for X SpecialProgram during the 2010/2011 school year. I planned to continue to add calculation fields each year to flag for the respective year. I am using a calculation field type for these fields. With the suggestion above, how do I link the SpecialProgram table with SpecialProgramEnrollment when their SpecialProgram is determined by a calculation?
Thanks so much for your help, greatly appreciated.
You may need to script that. It's difficult to make detailed description of the proccess without knowing more about the way this data is sctructured, but if you can perform a find to pull up all students that meet the criteria for a given program, a script can then loop through that list and enroll them if not already enrolled in the program. A calculation field, filtered portal and/or filtered relationship may also still be a possible to find students eligible for a given program, but I can't say for sure.
I planned to continue to add calculation fields each year to flag for the respective year.
You might want to think about what your database will be like 5 years from now...
Thank you for your help and ideas, I was worried I was making it harder than it needed to be - but it sounds like I need to think of a smarter way to handle it.