Tom, Does your Client have another computer you could load/run the ACCDE on?  If it does run, then the problem is definitely with the Client's original computer.  I would then start checking for differences in hardware and software.  Is the Windows version, Office version, and Access version the same on both yours and the Client's computer?  Hope this helps!

Thanks for the information.

The only difference is the OS. I run Windows 11 and he has 10. Like I said, until two weeks ago the program worked on his computer perfectly.  I am still trying to find out what changed on his computer. Nothing has physically changed on his computer. Same hardware and software as before.

Client says he does not have another computer on the premises.

Have you tried clearing the Office Cache on the client's machine. It could be that something saved in the cache and now the ACCDE file keeps hanging on it. Deleting the files there would force Access to re-do the files and possibly clear whatever the issue is.

The Office Cache can be found at:

C:\Users\USERNAME\AppData\Local\Microsoft\Office\16.0\OfficeFileCache.

Note that the AppData folder may be hidden. You can typically delete all the files in the OfficeFileCache folder without concern, but it doesn't hurt to back them up in case.

Thanks Donald.  I'll try that tonight when he closes shop

Hi Tom, Could a Windows update be a possibility? Have you thought about trying it with a windows install prior to the time when the problem started? John

When closing the program, I transfer 3xTables to three different databases. These three databases contain ONLY the table; no forms, queries, etc.  The error occurs with each of the three transfer lines shown below. The database sizes for the transfer are:6.83MB, 1.99GB, and 8.16MB.  Since this worked so well before I cannot find what is making the transfers error out.  Any ideas?

CODE: DoCmd.TransferDatabase acExport, "Microsoft Access", "C:\RDC-POS\Tables\Sales\Liquor Store POS Exports Sales.accdb", acTable, "tblSalesDaily", "tblSalesDaily" & a

a=string=20260607 (today's date)
The database files exist
The database paths exist

If that wasn't a typo, is there any chance the error is coming from the fact that the table has reached and or would exceed the 2 GB for that 2nd transfer?

I agree on the 2xGB limit but how does it explain the other two transfers.

Good question. Is it processed as a transaction - if one fails, they all do/get rolled back?

Beyond that, I would review John's suggestion about a Windows Update issue. If it used to work on that machine and now doesn't and it works on your machine... Another thing would be to verify that somehow the folder permissions didn't get changed somehow (can happen during windows updates) and verify that the user account running the database has read/write permissions still.

Other things that came up in my searches on the subject:
1) (You Probably already did this): Open the back up file you're exporting to directly and run compact/repair
2) Then, again, run compact repair on frontend file
3) Before restarting the front or backend of access, press Win+R to open the run dialog on the machine and type "%temp%". This will take you to the Windows Temporary folder. Delete all files in there, skip any that are in use. Access uses this folder when doing compact/repair and export/import operations. I might even consider doing another compact repair after deleting.

If that still doesn't fix it, there may be a corrupted index or memo field. Maybe the client computer doesn't have as much available memory to process it and your does.

One thing that jumps out at me is that one of the destination databases is sitting at 1.99 GB. That's awfully close to Access's 2 GB limit, and I've seen databases start acting strangely when they get that large, even before they completely hit the wall. Since this only started happening recently after working fine for months, I'd definitely take a close look at that file first.

I'd also check the Office/Access build numbers between your machine and the client's machine. If the exact same ACCDE works on your computer but not on theirs, something in the Access engine or a recent Windows/Office update could be contributing to the problem. I had a problem recently with one of my databases. Worked fine on my workstation PC which had the latest build. Copied to my "server" machine. Crashed every time it loaded. Nothing I could do fixed it until I bit the bullet and upgraded that machine to the latest build also. Worked fine after that. Sometimes little tweaks the A-Team makes in the build of Access can make huge differences in how Access runs.

The other possibility is corruption in either the destination database or one of the indexes involved in the export. I'd try exporting to a brand-new empty database as a test. If that works, it points more toward a problem with the destination file than with the export itself.

Keep us posted on what you find. I'm curious to hear what the culprit turns out to be.

Along with this issue: I added tables into the directories earlier trying to increase the file size and repeat the error. At some point this created a new database named: Database.mdb which contains 1xTable---MySysCompactError. Does anyone know what this is?

From ABOVE:
1-Did it
2-This is not a split (exists on only 1 computer) But I did this on the file before/after creating the ACCDE file on client
3-I'll have to do this

That's a pretty significant clue. The MySysCompactError table is usually created when Compact & Repair encounters data or index corruption it can't fully resolve. I'd open that table and see what information it contains. If it identifies a specific table or index, that may be the source of both the TransferDatabase failure and the Error 3709 message. Given that one of your destination databases is already around 1.99 GB, I'd also be taking a very close look at that file for corruption or size-related issues.

Everyone,
I finally fixed this learning 2xNew things.
  1.You should think hard about "Compact on Close" when the database is used for "storage only"
  2. Be careful of database size

My program quit when I transferred tables (sometimes very large tables) to different storage databases (which worked). Unfortunately, when the storage databases got too big (#2 above; even if database was only 3MB in size), the databases could NOT "Compact on close).

SOLUTION: I removed the "Compact on Close" for the three storage databases (only the storage ones) and the program worked great.  Just to be safe, I also broke the storage databases into different sections to keep them small. This is OK because they are only used for minor purposes and are deleted at the end of the year.

Thank all y'all for the directions and help.

In the great words of JTKirk: “There’s another way to survive — mutual trust and help.”

Yeah, I've always been wary of auto compact. I don't like it at all. I think you should compact deliberately and manually, once a month or once a week, depending on how often your database gets used. And definitely be aware of database size.