Depending on how you've set up your datasource/tables in the database your description sounds like the workflow is like this:
1. Open form
2. Select customer name
3. Data from database will auto-populate
4. Add to list of allergies
5. Submit changes
6. Select another customer name
7. Data from database will auto-populate
8. Add to list of allergies.
repeat
In your database I would expect to find a table which represents a one-to-many relationship for each customer unique id relating to a set of records containing their allergies.
e.g.
Table 1 - Customers
custId (autonumber) Name
1 Bob
2 Jane
Table 2 - Allergies
recordId (autonumber) custId Allergy
1 1 Bees
2 1 Dust
3 2 Pink
4 2 Peanuts
Your form main data source should include both tables with a relationship to link the tables together (the wizard usually lets you continue to 'add table' to the datasource and defined which fields in each table are linked)
When you Query your main datasource, the allergy table records will also be retrieved and the number of repeating text boxes (or any other repeating control) should alter to match the number of records and display them.
If you allow adding to the repeating text boxes/controls then after doing so the user must Submit the changes - otherwise the database won't be told to add the new allergy records.
Then you can allow a new customer name selection, requery the database - and repeat as needed.
You could put the rule to requery the database on the drop down list of names.
A key point is that in database design it is often necessary to have a 'record Id' (primary unique key) field so that applications such as Infopath can easily identify which record in a table they need to update.
I generally find a plain Autonumber field is fine.
Without a sufficient unique field (or set of fields) the program may produce an error/warning, or simply not allow you to make any submit or record changes.