You can do it by referencing the MAX value of the date column in the archive
table by means of a subquery:
INSERT INTO YourTable_Historical
SELECT *
FROM YourTable_New
WHERE BillingStatusDate >
(SELECT MAX(BillingStatusDate)
FROM YourTable_Historical);
The first point at issue, though, is whether you should have an archive
table at all. What it is doing is in effect encoding data (the fact that a
row is 'historical') as a table name. In a relational database data should
be stored only as values at column positions in rows in tables. In your case
you could add a Boolean (Yes/No) could named 'Archived' or similar and set
this to True when a row is archived. To work only with current data you'd
use a query 'WHERE NOT Archived'.
This assumes that with your present arrangement all values in the two tables
will remain the same. If after archiving a row values in the 'new' table can
change, however, then obviously a second table is needed. However, this
table should only contain the key column(s) necessary to relate the two
tables one-to-one and the columns whose values can change vis-Ã -vis the two
tables. This avoids the redundancy which having columns whose values will
remain the same vis-Ã -vis the two tables, and, the crux of the matter, the
possibility of inconsistent data to which this gives rise. While this might
seem unlikely, good database design respects Murphy's Law, which states that
if something can go wrong then sooner or later it will go wrong.
Nobody would be so proscriptive as to say you must not keep your present
arrangement. The choice is yours, but you should be aware of the design flaw
and the risk of inconsistent data resulting from it.
Ken Sheridan
Stafford, England