Sometimes the first activation of a segment in a document results – after a long time of searching the TM – in this error message: “An error has occured whilst using the translation  provider [TM]: The translation memory data file engine returned an  error: The database file is locked. Database is locked.”

Several people have reported this problem, and various methods to solve it has been tried (this is taken from the invaluable TW_Users forum):

“The affected TM in most cases seems to be the very last (or one of the last) in a list of – say – 6 or 7 memories. So it looks like Studio is simply ‛running out of steam’ by the time it reaches the last memories in a list. I can simply recativate the affected memory and everything works fine until at some later point Studio again thinks it is ‛locked’. If I deactivate all other memories and only activate this ‛locked’ memory, it works fine.”

“Re-indexing the TM helped to get that working.”

“If I deactivate all other memories and only activate this ‛locked’ memory, it works fine.”

My own experience is that this only happens with very large TMs, but then it can happen even if that is the only TM I use. I have not tried re-indexing, but I have found that the following method works fine:

Continue to the next segment – which then strangely is looked up in the TM without problem (regardless of whether there is a hit or no). Then go back to the “problem” segment and confirm it. (And delete the error message in the Messages window.)

Googling for “Database is locked” gives quite a few hits, related to SQLite, and it seems to be quite a common issue with other applications.

Related to the fact that the error-producing search takes a very long time is the sometime complaint that a concordance search may take very long (in a large TM). This is simply because concordance searches are very resource-intensive.