sqlite 格式错误的数据库仅在本地
我的网站上托管了一个 SQLite 数据库，它运行良好。我需要添加一些新的查询，并且我喜欢在上线之前在本地测试它们。
问题是，在我下载数据库文件以在本地使用它之后，当我尝试运行查询（与在线工作相同）时，我收到“数据库磁盘映像格式错误”。
知道问题出在哪里吗？
我的网站详细信息
服务器：linux
SQLite 3.x 的 PDO 驱动程序：已启用
SQLite 库：3.3.7
我的本地详细信息
服务器：带有 XAMPP (1.7.2) 的 Windows 7
SQLite 3.x 的 PDO 驱动程序：已启用
SQLite 库：3.6.16
I have a SQLite db hosted on my website and there it works fine. I need add some new query and I like to test them locally before going live.
The problem is that after I download the db file to work with it locally, when I try to run a query (the same that works online) I get a "database disk image is malformed".
Any idea where the problem is?
My website detail
Server: linux
PDO Driver for SQLite 3.x : enabled
SQLite Library : 3.3.7
My Local details
Server: Windows 7 with XAMPP (1.7.2)
PDO Driver for SQLite 3.x : enabled
SQLite Library : 3.6.16
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如何将 SQLite3 DB 文件下载到本地系统？
如果您在服务器在线时使用 FTP 或 SCP 之类的工具直接获取它，您很可能会检索到损坏的文件。想一想：通过互联网，传输这样的文件至少需要几秒钟——在这几秒钟内，您的站点仍然在线并且在服务器数据库文件上执行事务。因此，文件的前几个字节将反映事务 1003，而最后一个字节将反映事务 1015。本质上，数据库文件在您仍在下载时会发生变化。
我们还没有进入数据库日志文件和部分事务。
您需要的是数据库文件的原子副本。即使服务器上的
cp也可能不够快。您需要一种在复制文件时锁定数据库的方法。可通过三种方法执行此操作：
在服务器上使用
sqlite3shell 实用程序，并使用.dump数据库。然后，您可以压缩 SQL 转储、下载它并重建本地数据库。有点麻烦，但几乎可以保证工作。使用SQLite3备份API。 sqlite3 shell 实用程序 有一个
.backup命令，它几乎可以执行以下操作：相同的。然后你就可以下载新的数据库文件了。不幸的是，较旧的 SQLite 版本可能不支持此功能。使用sqlite3 shell实用程序锁定数据库文件，使用
cp复制它，解锁。旧的、稍微危险的方法，这就是为什么我不会详细介绍。停止您的服务器，以便不执行任何事务，复制文件，然后重新启动。我不认为这是一个实际的解决方案，因此它不包含在最终计数中。
顺便说一句，此页面包含一些损坏 SQLite3 DB 的常见方法 - 您可能想要一个看...
How do you download the SQLite3 DB file to your local system?
If you use something like FTP or SCP to get it directly while the server is online, it is quite possible that you will retrieve a corrupt file. Think about it: over the Internet, transferring such a file would need at least a few seconds - a few seconds during which your site is still online and transactions are performed on the server DB file. So the first bytes of the file would reflect e.g. transaction 1003, while the last bytes would reflect transaction 1015. Essentially the DB file changes while you are still downloading it.
And we still have not got into DB journal files and partial transactions.
What you need is an atomic copy of the DB file. Even
cpon the server may not be fast enough. You need a way to lock the DB while copying the file.There are three ways to do this:
Use the
sqlite3shell utilty on the server and.dumpthe DB. You can then compress the SQL dump, download it and rebuild a local DB. A bit cumbersome but almost guaranteed to work.Use the SQLite3 backup API. The sqlite3 shell utility has a
.backupcommand that does pretty much the same. Then you can just download the new DB file. Unfortunately older SQLite versions may not support this.Lock the DB file using the sqlite3 shell utility, use
cpto copy it, unlock. The old, slightly dangerous way, which is why I'll not go into more details.Stop your server so that no transactions are performed, copy the file, restart. I don't consider this an actual solution, hence its not being included in the final count.
BTW, this page contains a few common ways to corrupt an SQLite3 DB - you might want to have a look...