Validation rules that involve more than one field usually don't work well or don't work at all.  Suppose you manage to set up such a rule, when you enter CustomerAccountType as "11 Retail Military", Access will immediately throw you an error because *you haven't entered Occupation yet*; it's still blank.  To Access, that is a false condition, because CustomerAccountType equals "11 Retail Military" but Occupation is not "50 Military".  Since you can't enter both fields at the same instant, this validation rule will always give you an error.  And that's why validation rules involving 2 fields or more can't work.

To solve your problem, you likely require VBA to create a flexible logic.  When you enter "11 Retail Military", Access should automatically enter "50 Military" as the occupation.  When CustomerAccountType is not "11 Retail Military", Access should automatically clear the value of "50 Military" if it's there.  You need VBA to do all this.

William, if both values are stored in the same record, a table-level validation rule can enforce this. The important distinction is field validation versus record validation. A record validation rule checks the combination when the record is saved, so you can finish selecting both values first.

Kevin's suggestion is useful if you also want the form to automatically fill in or clear the occupation. That is separate from rejecting an invalid combination at save time.

Assuming the fields are named CustomerAccountType and Occupation and actually store the numeric codes 11 and 50, the table's Validation Rule would be:

([CustomerAccountType]=11 And [Occupation]=50) Or ([CustomerAccountType]<>11 And [Occupation]<>50)

Put this in the table's Property Sheet, not an individual field's Validation Rule. Add Validation Text explaining the allowed pairing. If both selections must be completed, set both fields' Required properties to Yes; the comparison alone does not reliably reject Nulls. If blanks are allowed, decide their rules separately.

Check what each combo box's bound column actually stores, rather than its displayed description. Text codes need quotes, and different field names need substituting.

My Table-Level Validation video demonstrates the record-level setup. Test the valid and invalid pairings on a backup copy first.

Richard   Here is one instance where the rarely used XOR operator (exclusive OR) can be used:

     [CustomerAccountType]<>11 XOR [Occupation]=50

If you need mutual exclusivity (both conditions can't be true at the same time, or false at the same time), use XOR.

The reverse of the above also works:

     [CustomerAccountType]=11 XOR [Occupation]<>50


P.S.

Implementation of XOR can be found right in our homes.  Suppose you have two light switches, one in the 1st floor and one in the 2nd floor, that control that same set of lights.  In order for the lights to turn on, both switches cannot be at the On position (True) or Off position (False) at the same time.  One has to be On and the other one Off, and vice versa.