Because the find/replace dialog doesn't help you to directly alter a table's contents in this particular way, you will need to do one of two things. Either (A) write code to step through a recordset to apply a special parse/reformat function or (B) write a public function that "wraps" the code to apply the parsing/formatting.
In either case, the code would have to first decide whether the current number actually qualifies for this reformatting, and then it would have to reformat the number string.
IF you have a public function that tests and returns the correct string, you can write an SQL query to step through and update the records. I would choose the SQL UPDATE method ONLY because if you did it via recordset, that is all done in VBA and unfortunately, VBA is a LOT slower than performing recordset operations through SQL. For thousands of records, VBA might be painfully slow. I have a related case where I get a file in UTF-8 format and have to convert it to ANSI text and that little problem takes forever. Not that hard to correct the UTF-8 extended character to something usable, but it takes forever to find the problem in the first place. So a raw VBA-only approach isn't so good.
A point was raised by Gasman that not all postal designations should get the "comma" treatment. For example, USA ZIP codes are always 5 digits for which that comma would probably screw up the automated postal sorting machines. Even worse, the ZIP+4 codes have a 5-digit and a 4-digit number together and NEITHER should receive the "comma' treatment. This means that your parsing approach is going to be important as well.
