iOS应用程序中由SQLCipher加密的数据库将永久无法访问

我最近修改了iOS应用程序，为使用SQLCipher加密的数据库和未加密的数据库（也叫SQLite）启用序列化模式。我还为每个数据库维护一个静态sqlite3连接，每个数据库只打开一次（通过简单地检查空值），并在应用程序的整个生命周期内共享

该应用程序需要有一个类似同步的行为，它将使用soap请求定期从远程数据库下载大量记录，并更新本地加密数据库的内容。当然，使用该应用程序的人可能正在更新或读取数据库，也可能不在更新或读取数据库，这取决于他们在做什么，所以我做了上面一段中提到的更改

在做短期测试时，事情的工作方式似乎没有任何问题，我也遇到过任何问题

然而，一些用户报告说他们失去了对加密数据库的访问，我正在试图找出原因

我的想法如下：另一个开发人员编写的方法声明所有sqlite3_stmt都是静态的（我相信这段代码在有问题的版本中）。在过去，我注意到当两个使用特定方法的线程同时运行时崩溃。一个线程在另一个线程使用sqlite3时完成、修改或替换sqlite3。崩溃并不总是发生，因为他将大部分SQLite代码包装在try/catch块中。如果SQLite确实使用prepare和finalize来实现锁定，那么在这种情况下，SQLite 3_stmt的孤立（由于其静态特性而发生）是否会使数据库处于不可操作的状态？例如，当一条语句在被步进后获得一个排他锁时，它会被另一个线程中运行的同一方法中的赋值所替换吗

<>我意识到这并不一定意味着数据库将永久无法使用，但是，请考虑这个场景：

在应用程序生命周期中的某个时刻，它将对加密的数据库重新设置密钥，并且该密钥存储在另一个数据库中。假设它成功地为加密的数据库重新设置了密钥，但是由于我上面提到的原因，新密钥没有存储在另一个数据库中。 如果数据库在某个时候没有损坏（我真的不指望会发生这种情况），这是我能想到的唯一解释，解释为什么用户在重启iOS应用程序后可能无法使用加密数据库，因为该应用程序将是唯一访问数据库文件的应用程序

---

由于我无法重现这个问题，我只能推测可能的原因。你有什么想法？对于很少发生的事情来说，这似乎是一个合理的假设吗？您是否有其他想法需要研究？

如果数据库被重新设置密钥，并且数据库的密钥未成功存储在其他数据库中，则肯定会导致问题。

您对第五段有何看法？这似乎是一个合理的解释，为什么密钥不能存储在未加密的数据库中？是的，这就是我的意思。假设在应用程序生命周期的某一时刻，您对加密的数据库重新设置了密钥。这就完成了，现在使用一个新密钥对其进行加密。但是，由于您提到的静态sqlite3结构的问题，第二个数据库中加密密钥的更新将丢失。现在主数据库无法访问。在不知道程序的确切结构的情况下，很难获得比这更具体的内容，但这肯定是一个潜在的问题。