Some thoughts for your consideration:
and cause you headaches.
your key? Does this table have a primary key?
download, or update your existing records -- if the CostCenter/Project-Comp#
unique constraint holds, you couldn't add another one, right?
Comments (and when finished, the DateOut), why are you replacing the entire
record, or adding a new one? This sounds like your Access table has not
been normalized sufficiently. You might want to consider a different table
design -- one that records a single row for the "facts" that don't change (a
"parent" table), and a second table for whatever it is you are downloading
and "updating/appending" (a "child" table). This second table is related to
the first with a "foreign key", which is a "copy" of the primary key in your
"parent" table. Now the question of what determines a unique row in your
parent table comes back into play.
historical/archive/... table, you're creating more work for yourself.
Another approach is to come up with a way to treat a row as "historical",
even while leaving it in the same table. From what you've described, any
row with a DateOut is, by definition, historical. Why not leave it there?