Upon startup, you get this error:
DBISAM Engine Error # 11013 Access denied to table
and it mentions a path/file containing: ...\TEMP\ClipMate7Temp
This error has crep up a few times lately. The database is trying to create some temporary work tables in the "temp" area of your hard disk. But it can't. There are some known, possible causes:
- Your anti-virus program is interfering. Solution: Configure your anti-virus program to leave that directory alone.
- You have a cleanup script set to delete your temp directory at startup. Solution: Omit the ClipMate6Temp portion of the directory from the cleanup. Or, delay ClipMate's startup for 20 seconds (or so), to allow time for the cleanup to run. See Config | User Preferences | Advanced | Startup Delay
- Your TEMP and TMP environment variables are not set correctly. See Control Panel | System | Advanced | Environment Variables. They should both point to a valid directory, where you have "write" permission. This is rare that it would be mis-configured, but we've seen it (we've seen it all).
To test permissions, look and see if the directory named in the error does indeed exist. If so, see if you can create a new file in there. Using Windows Explorer, right-click within the directory, select NEW | Text Document. Call it TEST.TXT. If you can create the file, then your permissions are ok.
UPDATE: We've changed the default location for temp files with ClipMate 6.2. Please update to this version, and then it should store the temp files in the database directory.
UPDATE: March 31, 2005 - this is getting to be a major problem for many developers using the DBISAM database engine. Norton Antivirus is causing the errors by holding the temp files open too long, denying access to the application (ClipMate). We're looking at a long-term solution (only non-violent solutions are being seriously considered). If you are using Norton Antivirus or McAffee, configure them to NOT scan for .DAT files in ClipMate's database directory. While preventing the 11013, you'll also speed up the database access considerably.
- Symantec article talking about how they mess up Exchange Server, in a similar fashion: http://urlmini.com?i=594