如果文件位于远程文件夹(如共享文件夹)中，则可能引发此错误。我将数据库更改为本地目录，它工作得很好。

SQLite wiki DatabaseIsLocked页面提供了此错误消息的解释。在某种程度上，它指出争用的来源是内部的(对发出错误的进程而言)。本页没有解释的是SQLite如何决定进程中的某些东西持有锁，以及哪些条件会导致误报。

当您试图从同一个数据库连接同时对数据库执行两项不兼容的操作时，就会出现此错误代码。

在v3中引入的有关文件锁定的变化可能对未来的读者有用，可以在这里找到:SQLite版本3中的文件锁定和并发性

我刚才在远程服务器上使用存储在NFS挂载上的SQLite数据库时遇到了这个问题。当我使用的远程shell会话在数据库打开时崩溃后，SQLite无法获得锁。

上面建议的恢复方法对我不起作用(包括先移动然后再复制数据库的想法)。但是在将其复制到非nfs系统后，数据库变得可用，数据似乎没有丢失。

我只是犯了同样的错误。 5分钟后，我发现我没有关闭一个shell巫婆正在使用db。 请关闭它，再试一次;)

有些函数，比如INDEX'ing，可能会花费很长时间——而且在运行时它会锁定整个数据库。在这种情况下，它甚至可能不使用日志文件!

因此，最好/唯一的方法来检查您的数据库是否被锁定，因为一个进程正在积极地写入它(因此你应该让它独自呆着，直到它完成它的操作)是md5(或md5sum在某些系统)文件两次。 如果你得到一个不同的校验和，数据库正在被写入，你真的真的真的不想杀死这个进程，因为如果你这样做，你很容易得到一个损坏的表/数据库。

我要重申一下，因为这很重要——解决方案不是找到锁程序并杀死它——而是找出数据库是否有一个很好的写锁，然后从那里开始。有时候正确的解决方法就是喝杯咖啡休息一下。

The only way to create this locked-but-not-being-written-to situation is if your program runs BEGIN EXCLUSIVE, because it wanted to do some table alterations or something, then for whatever reason never sends an END afterwards, and the process never terminates. All three conditions being met is highly unlikely in any properly-written code, and as such 99 times out of 100 when someone wants to kill -9 their locking process, the locking process is actually locking your database for a good reason. Programmers don't typically add the BEGIN EXCLUSIVE condition unless they really need to, because it prevents concurrency and increases user complaints. SQLite itself only adds it when it really needs to (like when indexing).

Finally, the 'locked' status does not exist INSIDE the file as several answers have stated - it resides in the Operating System's kernel. The process which ran BEGIN EXCLUSIVE has requested from the OS a lock be placed on the file. Even if your exclusive process has crashed, your OS will be able to figure out if it should maintain the file lock or not!! It is not possible to end up with a database which is locked but no process is actively locking it!! When it comes to seeing which process is locking the file, it's typically better to use lsof rather than fuser (this is a good demonstration of why: https://unix.stackexchange.com/questions/94316/fuser-vs-lsof-to-check-files-in-use). Alternatively if you have DTrace (OSX) you can use iosnoop on the file.

我在使用Delphi和LiteDAC组件时得到了这个错误。 事实证明，它只发生在运行我的应用程序从Delphi IDE，如果连接属性设置为True的SQLite连接组件(在这种情况下TLiteConnection)。