in actual fact you can take advantage of the way that Access / JET stores dates whichis numeric the most significiant digits represenbt the number of days since (IIRC 01 Jan 1900), and the decimal = proportion of days eg .5 = 12:00, .75 = 18:00, 0.0416666666666667 an hour)
so you could run two queries
eg
update mytable set mydatecolumn = date1 where date1 >= date2
update mytable set mydatecolumn = date2 where date2 >date1
or
update mytable set mydatecolumn = iif(date1>= date2, date1, date2)
mind you it does beg the question why you'd want to store such derived data as you can always find the correct date in the query by using the iif clause above. storing derived data is a no no..
why?
what happens if later on somebody changes the values of one or more date columns, then you have to rerun your process to set the new date.
there are times when you can and should store what at first glance seems derived data. ferinstance on an order, the order details probably should list the price the goods were sold at, the prevailing sales tax rate (or value), the order header should record the actual customer. so you do not want to change those items if say your sales tax rate goes up, the supplier changes or changes name and so on.