Running a delete
query is the direct cause of the bloat. SQL does not garbage-collect its memory space because to do so, it would have to run the equivalent of a C&R to find all of those deleted records. That "dynamic" C&R operation requires exclusive access to the DB. It is usually NOT the import operation that causes bloat - it is the preceding step to get old obsolete data out of the way while the DB is still running. If you had instead chosen to update your table from the new data by building VBA to read the Excel file line-by-line, you would ALSO get serious bloat.
Notice that earlier I didn't suggest your table structure was bad. I said you had a bad OPERATIONAL structure. The way you are dealing with that external data source, the way you have to operate on the data, is what I meant by that. By replacing the whole table, you make the entire prior contents of that table obsolete. The "straight-through" method of deleting what you
don't want then importing what you
do want is your problem. You need the subtlety of the "template" approach to not cause bloat. Since your discussion suggests that you are the only person who would do this, just doing it by hand would work. However, if you program it you would have more reliability.
Here is a starting point. Look up and carefully explore this topic: FileSystemObject.
Office VBA reference topic
docs.microsoft.com
That link gets you to the Microsoft "Docs" site. Using the tree-like structure on the left of that page, you can drill down to explore topics including how to do file copy operations and file delete operations programmatically. VBA and the "FSO" work together very well and in fact, for what you need, VERY simply.
Actually I understand that, and have been known to be a "bull in a china shop" looking for a better way - and breaking a bunch of things along that path to the better way. Pat and I (as well as many others in the forum) have LOTS of experience with bloat. The problem with bloat isn't fixing it. It is fixing it in a way that doesn't disrupt others and/or in a way that doesn't tie up the database for a very long time trying to unravel everything and/or in a way that doesn't leave a mess behind you.
If you are a student of ancient history, you will have heard of Alexander the Great and his solution for untying the Gordian Knot. His solution was to take out his sword and cut it apart. Well, the C&R method is analogous. You don't untangle the blocks of deleted data. Instead, you make a new empty file and then extract everything you wanted to keep into that new file, then delete the old file in its entirety. (That IS the way a Compact & Repair operates!) The "Template" method is simply a way to selectively delete the old pile of obsolete data, create a new file, and re-tie the knot.