A family of Microsoft relational database management systems designed for ease of use.
That's very easily done by with your present set-up by basing the form on the following query, in which I've assumed that the first table is named Contacts:
SELECT FirstName, LastName,Address,
Contacts.City, [Zip Codes].Zip, State
FROM Contacts INNER JOIN [Zip Codes]
ON Contacts.City = [Zip Codes].City
ORDER BY LastName, FirstName;
But this is going to work for the following reasons:
1. City names are not distinct, so are unsuitable as keys. You would have to use a numeric surrogate CityID key of distinct values.
2. US cities have many zip codes each, so Zip is not determined by City, so the Zip Codes table needs to be decomposed into four tables as follows:
Cities
….CityID (PK)
….City
….StateID (FK)
States
….StateID (PK)
….State
ZipCodes
….ZipCode (PK)
CityZipCodes
….CityID (FK)
….ZipCode (FK)
The primary key of this last table is a composite one made up of the two foreign key columns.
The Contacts table should have a numeric CityID column in place of the City column, and the State column should be removed from the query as this is determined by CityID. The form should, therefore be base on a query which joins Contacts, Cities and States. The state will show automatically when you select a city in a combo box bound to the CityID column. To select a zip code you will need a 'correlated' combo box bound to the Zip column, whose RowSource is a query which restricts the zip codes in the combo box's list to those for the selected city, as determined by the rows in CityZipCodes. As it happens I've done exactly this recently in a project I've been undertaking on a pro bono basis for an organisation in the USA.