Two individually valid dates can make an invalid pair. A booking that ends before it starts needs a rule about the record, while a missing date needs a separate completeness decision. Write both requirements before adding validation.

Use a disposable desktop Access table with Date/Time fields named StartDate and EndDate. For this example, both dates are mandatory and an end equal to the start is allowed. That policy is deliberately explicit; a workflow permitting unfinished draft bookings would need a different completeness design.

Apply the comparison at record scope

Access record validation can compare fields in the same table and is checked when leaving the record. Open the table, choose Table Fields, Validation, Validation Rule and enter [EndDate]>=[StartDate]. Use Validation Message to provide a clear correction instruction. A field rule or a rule on one form control has a different scope.

For each required date, open table Design View, select the field and set Field Properties, General, Required to Yes. Microsoft documents this as requiring a supplied value. Do not rely on the date comparison alone to reject a missing endpoint.

Test the moment the record is saved

Prepare four fictional cases with known dates: 2–4 October 2026, 2–2 October, 4–2 October, and 2 October with no end date. The declared policy accepts the first two and rejects the last two for different reasons: reversed order versus missing required information.

Attempt to leave each record after entry and inspect the response. A record-level rule may wait until that transition, so simply typing an end date and seeing no immediate warning does not complete the test. Confirm that a valid corrected pair can then be saved.

For an existing table, use Design View, Table Design, Test Validation Rules to inspect stored data against the new rule. Read the prompts rather than assuming an added rule retroactively repaired older records. The Required setting also offers an existing-value check; review that result separately.

Keep the accepted date-pair cases with the database change. If real users need to save partially completed bookings, resolve that requirement before imposing mandatory fields. The useful result is a table-level rule that matches the agreed lifecycle, with clear evidence for both ordering and completeness.

Sources: Microsoft: record validation rules; Microsoft: supporting procedure.