为什么 DBD::SQLite 不能通过我的 Perl CGI 脚本插入数据库？
我正在 Perl CGI 脚本中运行 SQLite 数据库，该脚本由 DBD::SQLite。 这是在 Apache 上作为直接 CGI 运行的。
DBI 连接工作正常并且可以运行选择。 但是，当我尝试执行插入操作时，出现以下错误：
DBD::SQLite::st execute failed: unable to open database file(1) at dbdimp.c line 402 at index.cgi line 66
我已尝试将数据库文件权限更改为 666 以尝试修复此问题，但我仍然收到错误。
有什么建议吗？
I am running a SQLite database within a Perl CGI script which is being accessed by DBD::SQLite. This is being run as a straight CGI on Apache.
The DBI connection works fine and selects are able to be run. However, when I attempt to do an insert I get a die with the following error:
DBD::SQLite::st execute failed: unable to open database file(1) at dbdimp.c line 402 at index.cgi line 66
I have tried changing the database file permission to 666 to try to fix this however I am still receiving the error.
Any advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
看起来该目录需要写权限，原因是：
来自：似乎需要对数据库父目录的写权限
It looks like the directory needs write permission, the reason is:
From: seem to need write permission on db's parent directory
SQLite 在执行插入和更新时会暂时锁定整个文件（没有记录级锁定）。 您确定要释放锁吗？
SQLite 文献建议您启动一个事务，收集该事务中的所有插入和更新，然后提交。 这可以避免多次连续的文件锁定，并提高性能。
SQLite momentarily locks the entire file when it is doing inserts and updates (there is no record-level locking as such). Are you sure you're freeing the locks?
The SQLite literature recommends that you start a transaction, collect all of your inserts and updates du jour in that transaction, and then commit. This avoids numerous successive file locks, and improves performance.
由于 SQLite 锁定整个数据库文件，因此您可能需要使用基于超时的重试机制。 当我问这个相关的
我最终写了一些类似于 Mark Fowler 的 Attempt 的内容，如果抛出异常则重试by sub 匹配正则表达式，在我的例子中：
Since SQLite locks the entire database file, you may want to use a timeout-based retry mechanism. I was working on pretty much the same problem when I asked this related question.
I ended up writing something similar to Mark Fowler's Attempt that retries if the exception thrown by the sub matches a regular expression, in my case:
db 文件所在目录的路径应同时设置可执行位和可写位，以便从脚本访问它。
此外，如果您不希望直接访问 db 文件（即使不使用特殊的服务器文件），它也应该具有访问权限，例如 600，并且如果不应直接浏览包含的目录（同样，即使不使用特殊的服务器文件），它也应该具有访问权限，例如 700。< br>
我使用这个设置，它在本地和我托管站点的服务器上都运行良好。
当然，如果内部存在任何其他文件，则包含目录的权限不能为 700它应该可以通过 html、css 或 javascript 访问。 应该是755。
The path to the directory where the db file resides should have both executable and writable bits set, in order to access it from the script.
Furthermore, if you don't want the db file to be directly accessed (even without the use of special server files), it should have access permissions such as 600 and if the containing directory should not be directly browsed (again, even without the use of special server files) it should have access permissions such as 700.
I use this setup and it works fine both locally and on the server where I host my site.
Of course, the permission of the containing directory cannot be 700 if there exists any other file inside it that should be accessible via html, css or javascript. It should be 755 instead.
如果您不想按照 Todd Hunter 的回答中的说明对整个目录设置写权限，则可以设置
journal_modePRAGMA 为“MEMORY”。在这种情况下，请注意：
因此这是否是一个好的解决方案取决于您的数据库以及它的使用方式。
其他人还提到了 temp_store pragma。 我不需要设置它，但这可能取决于数据库的使用方式。
因此，在 Perl CGI 脚本中，您可以尝试以下操作：
If you don't want to set write permissions on the whole directory as explained in Todd Hunter's answer, you could instead set the
journal_modePRAGMA to "MEMORY".In that case, beware that:
So whether this is a good solution depends on your database and how it is used.
Others also mention the temp_store pragma. I didn't need to set that, but it may depend on how the database is used.
So in your Perl CGI script, you could try this: