Other Comments
There are several other features of the system that aren't highlighted here, primarily because they don't have
much of a visual component. One of which is the tuition setting procedure. The tuition value is used to
make calculations when a student receives tuition reimbursement. This value is stored in the ASP object
model at the Application level. Of course, one of the problems with this is that if the server were
rebooted or another Global.asa file were saved, the application level variables would be reset. This
value cannot be hard-coded either, as it changes over time. The solution was a short but interesting
backup storage script that saves the value both in the variable and in a text file. If either of these
is missing, it fills in the other. That way, if the application is restarted and sees that it has no
value for that variable, it can pick it up out of the text file.
There is also an interesting feature that allows administrators to define common mistakes for company names.
This is done in order to preserve data integrity in the database. If a student doesn't find their
company in the list, they may add it as a new company. In some cases, there may be two different
(but similar) names for the same company, and we don't want duplicate entries in the database. By
defining common mistakes, administrators can define certain key entries which, if entered by a student,
should suggest an existing company name that the student might have overlooked.
Finally, there are several automated e-mail components built into the system. Nightly, the system checks
who accepted an offer that day and notifies the administration. In addition, whenever events that might
require administrative attention take place, such as accepting and later declining an offer takes place,
an e-mail is sent notifying the administration of such an event.
|