Hi Kristen
Two things come to mind - both based on your description, and which may or may not be helpful.
If you have "a static set of skills that all employees are rated on", then this sounds like a separate table - EmployeeSkillRatings, with a layout something like this:
EmployeeID
Skill1Rating
Skill2Rating
Skill3Rating
.
.
SkillnRating
In this way you would need to add only the ratings (and if this is not historical data, maybe not even that - add the ratings after the employee is evaluated).
You could also add those fields to the main table as fields, rather than typing in each Skill. (This is what it sounds as if you are doing).
Second thing that occurs to me is that you have a rather un-normal table. (I resisted the immediate desire to say abnormal ;-)
Because you have an entry for each empooyee which has multiple skills in it, you are in deep trouble if you ever add a skill. Even if you allow for "more than I'll eve need", folk-lore and bitter experience will tell you that "ever" is a very short time.
What would be better, perhaps, would be to have a table of Skills:
SkillID
SkillName
and then a table of employee skills looking like this:
EmployeeID
SkillID
EmployeeSkillRating
This way you can have as many or as few skills as you like. And you can then use a combo box to select a skill (preserving the uneditability of it), and a text box for the rating.
Even if you change the underlying database structure, you can still do this on the one form, you simply have to allow for adding multiple skills, and indicate (somehow - a command button?) that you are done with this part of the process.
I'm also in New York, so if you'd like to chat off-line I'd be delighted to help.
Tony