Suggest you base a form on a query on this table rather than the table itself. I don't see why this couldn't/wouldn't be a form with textboxes for the server details, and an unbound combo box whose row source is a query on your server field in your main table. If you want to filter the server list as a user types in the combo box, this is a fairly easy and common topic. If you Google "ms access combo box filter as you type" you'll get tons of hits. Pick one that closely resembles your setup (i.e. considering text vs numbers in a list or anything else that may be relevant to you). The reason for the query suggestion is that it can provide more flexibility going forward. Just make sure that it can be edited before you create the form, and any time you modify the query structure.
Note: Date is a reserved word and should not be used for object or variable names. It's also can become meaningless down the road. Something like ChangeDate, or ChgDte would be more helpful. If you adopt a proper naming convention, you will almost never have this problem.
EDIT: forgot to mention that I'm not seeing a need for a popup form at all. A single form can work (without the combo) whereby you just cycle through the records if there aren't too many. Another possibility is a form/subform with the main form containing the combo and the subform the detail textboxes. If the subform has navigation controls, you can cycle through only the records that are related to the combo box selected value. Then there is the split form, but I have to confess I've rarely used them, so I'm just throwing that out here. It may not apply to your situation, but it is something for you to investigate.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.