OK, I'll try explaining this differently, and to my colleagues, I'm just trying to get a point across because it seems to have not been made clearly. I make no claim of a new idea, just a new approach.
When you have these tables, I'm going to assume there is some value to be had in knowing from where the data originated (based on the name of the input file, for example). So in plain language (no code) this is what to do.
I'm assuming that the daily tables have similar or identical structures each day, just different contents. (If they don't, you have an impossible situation to organize.) Build as many tables as you need in the main database to "cover" the incoming file structures. If they are ALL the same structure, just different sources and contents, then you only need one main table. If a day's set of six files each has a different structure, but for any given day they have the same structure (from day to day), you need six tables, one for each structure. But that's ALL you need.
When you import the new tables, don't do it in your main DB. Instead, create (once, beforehand) an empty working database file. Or it can even have tables such as you might need for the incoming files' structures. Before importing anything, COPY the empty working DB to a new DB file. Open that (copied) database. Import the six tables including the name data into the working file. If you have to update the tables from those imported files to diddle formats or other tailoring, do it in the working file. Do whatever you have to do.
Now you have the names of the six files. Enter those names into a table that lists each file name, the date, and a unique index number for each table. This index COULD be an autonumber. Probably should be.
Using appropriate queries, import the data from the six new tables, appending the data to the main file with the matching structure. As part of that query, you include the index number of the file from which it came. So that means one extra field in each of the main tables to hold info about the data sources.
Now you can delete the copy of the working DB because you are done with it. This means that you don't have to do any other cleaning of your main DB because the dirty work didn't occur there. If you later need to know from where something came, you have the index to the table that recorded file name and date. But you renamed NOTHING in your main DB. And you deleted NOTHING. So you minimize two of the main sources of database bloat.
Sounds complicate? Yes, it is. But not much more complicated that renaming files every day and trying to track them in some obscure method.