Does the database have any attachments, OLE Objects, or may have the front ends accidentally have copied some images or icons into the gallery versus just linking them

Clifford, splitting the database does not prevent the front end itself from bloating. Design changes and temporary objects can increase its size even when the data lives in a separate back end.

Compact and Repair normally reclaims unused space, but it cannot repair every internal problem. Importing into a blank database copies the selected objects into a separately initialized database. The drop to 35 MB suggests that most of the old size was not needed by the imported application, but it does not tell us exactly what occupied that space. The size difference alone does not prove VBA corruption or embedded images.

Keep the original backup and check the table links, startup settings, references and any saved import/export specifications in the new copy. Then watch its size while repeating the tests that caused the rapid growth.

The Compact and Repair video explains normal space reclamation. Your case goes beyond simply needing to compact more often.

Are there any hidden tables?  You can unhide all tables to make sure.  We don't usually hide our own data, but you never know.

Thanks for some feedback.  It took 11 years for it to reach 1.5 GB and only 2 days to reach 2.1 GB.  My client asked that I combine multiple PDF reports into one file.  I researched how this could be done, including the use of .dlls ect. I chose to use a COM available with Adobe Acrobat.  It involves producing the individual reports then using the Acrobat COM to combine them into a single file.  Since I was doing this for numerous people at a time, I had to 'Kill' the original reports produced for each employee then recreate them for the next employee.  Most of my errors occurred when my code wasn't adjusting properly to changed file names and raised errors.
Is it possible, when the errors occurred and I had to stop the process that the report(s) suspended in the Print Preview mode became bloat in my frontend?
I will definitely keep an eye on any signs of bloat as I continue my development.
Thanks again,
Cliff

Cliff, the interrupted routine is worth investigating, but an open Print Preview does not establish what caused the permanent file growth. Access can leave temporary objects behind, so we need to isolate which stage is growing the front end.

Kill deletes the exported PDFs on disk. It does not close an Access report or reclaim space inside the database. It can also raise an error if the file is still open.

Give the routine a cleanup path for both normal completion and handled errors. Close the Access reports and Acrobat documents that your routine opened, then release the COM object variables. Delete the source PDFs only after the merged PDF has been saved and checked and the source files have been closed.

On separate backup copies, compare a small export-only batch with the full export-and-merge process. Check the front-end file size after closing Access, before and after compacting. Record any error number and filename. That will help distinguish report generation from the merge step without assuming the previews are the cause.