我在文件系统上有一个sqlite3文件，该文件系统属于与运行读取过程不同的用户。我希望读取过程能够以只读模式读取文件，所以我传递了SQLITE_OPEN_READONLY。我希望这能奏效。当然，我们的想法是只读模式适用于我们不想写入的文件吗？
当我准备第一个陈述时，我得到了
unable to open database file
同样，如果我运行sqlite3命令行工具，除非我sudo，否则我得到相同的结果。这似乎向我证实，问题是可写性而不是其他任何问题。
this question的答案似乎表明，如果周围有日志文件，则无法进行只读访问。
为什么有日志文件？因为另一个进程正在写入文件，我的用户进程正在尝试以只读方式打开它。为此，我使用了Write-Ahead Logging，它生成两个日志文件-shm和-wal。确实如此，如果我停止写入过程并删除日志文件，我的用户进程可以以只读模式打开它。
所以我有两种情况：
如果文件属于写入过程和只读过程，则预写日志记录允许进程A写入并将B处理为只读
如果文件属于写入过程，但不属于只读进程，则禁止只读进程以只读方式打开。
< / LI>我如何实现这两个目标？要拼写出来，我想要：
看起来像一套简单的要求，但我看不出明显的解决方案。
**编辑：**继续this documentation，看起来这是不可能的。您能否提出任何其他方法来实现上述目标？
答案 0 :(得分：1)
是WAL-journaled数据库无法以只读方式显式或以其他方式打开（即在数据库文件对进程只读的情况下）。
如果您要求绝对不允许只读进程修改数据库文件，那么唯一可以想到的是写入进程维护数据库的非WAL日志附加副本。
结论：据我所知，WAL和只读是无法完成的。
答案 1 :(得分：0)
我认为文档所说的是WAL数据库本身可能不会出现在只读媒体上，这并不一定意味着您无法使用SQLITE_OPEN_READONLY。实际上，我已经在WAL sqlite数据库上成功打开了两个连接，一个是读写，另一个是SQLITE_OPEN_READONLY。这些工作得很好。我使用只读连接测试了INSERT查询，并且语句正确地返回了数据库是只读的错误。
只需确保数据库存储在具有写访问权限的某些介质上，因为需要创建和维护-shm文件，因此即使是“就绪”连接也可能实际上在物理上将某些内容写入磁盘 - 这不是并不一定意味着它可以使用SQL修改数据。