This is the way I would do probably do it., using your database.
The VAT table now stores an autonumber ID field, and the rate. Just the rate value, not the percentage.
The product table stores the ID field, not the VAT rate. You would join the two tables to derive the VAT Rate.
If you change the selected value (ie to pick a different tax rate), the stored record ID changes in the product table.
I also changed the code in the not in list event.
Note that in the combo box, the values appear as left justified, as strings not numbers.
I would probably add a description field to indicate what the VAT rate represents, eg Standard Rate, Special Rate, Zero Rate, Exempt etc, or even a non UK rate.
Note that by storing the VAT Record ID, you might need to consider what happens if the rate changes. So you might need to include a mechanism to derive the old rate at the relevant date. eg, VAT in the UK changes from 20% to 22%. When you make a sale you might store both the VAT code AND the rate applicable at the time, to avoid having to look up old values. As far as the product goes, all you probably need is the type of VAT, and not the actual rate.
But you always have this problem. If the rate of VAT in the UK went up from 20% to 22%, everywhere you stored 20% in old data is OK. Everywhere you store it for new data needs to change. So you would have to change every VAT value in the product table. If you store a reference code, then you only have to change the VAT value once, in the VAT table, but you have to manage the rate of VAT according to the tax date applicable. (and according to sometimes arcane HMCR rules regarding the actual tax point date)
if you store 20 and 22 in the database then you have to divide the value by 100 to work out VAT
if you store .20 and .22 then you would not need to divide the value. It's a matter of taste really. Whatever suits your business.
I hope this helps.