>One customer is showing a collection of errors that we can't duplicate or correct for. In the majority of cases it works properly, but at random times, the same line of code (PACK a temporary table) will throw one of three errors:
>Error 1705: File Access Denied OR Error 52: No table is open in the current work area OR Error 1: File [temporary filename] does not exist.
>
>I've been fighting it for a while and have pretty much run out of ideas. Why is it throwing different errors at the same time and place? What is causing Exclusive use to fail or file not to be found?
>
>I've tried all the usual suspects and guarding the pack with USED(alias) and ISEXCLUSIVE() will hide the error but the same random set of errors appears farther along in the code where the file is used.

Is the temp table local, or on a network share? For the following I'll assume local.

These errors are variations of a single problem, that a file doesn't exist when it should. The most common cause IME is creating cursors from SELECTs without specifying NOFILTER, then referencing those cursors in subsequent SELECTs. Without NOFILTER cursors aren't guaranteed to exist on disk. I see you're using VFP6 so the READWRITE clause is not available in SELECT - SQL.

Ironically, these problems get worse when customers have new computers with tons of RAM, because there is a greater chance VFP or Windows can buffer a temp table or file without writing it to disk.

If you're doing heavy data munging with cursors, I'd first make sure to include NOFILTER in every SELECT that creates a cursor that could possibly be linked in some fashion to your temp table. Even if you don't see any such connection, try it anyways. ISTR a couple of head-scratchers of my own, where I did this merely because it was thematic, and it fixed the problem.

I've seen cases of strange behaviour when the local temp file folder has thousands of dead/orphan files. This can easily happen when a computer is used for several years and the folder has never been cleaned out. A PACK operation makes extra heavy use of temp files; this could be a factor. Maybe file-name collision, poor disk performance, ...

From the Fox Wiki http://fox.wikis.com/wc.dll?Wiki~Pack~WIN_COM_API : "Actually copies the records that are not marked for deletion to a new table then deletes the old table and renames the new one to the old one. Make sure you have enough freespace on the drive where the table is."

Do you have to use PACK? SET DELETED ON will ignore deleted rows automatically, including in SELECT - SQL. If you have DELETED set OFF and just need read-only access to undeleted rows you could SELECT ... WHERE NOT DELETED() INTO CURSOR NewOne NOFILTER for further operations. I haven't needed to use PACK for many years except in periodic (monthly/semiannual) database maintenance procedures.