Je gère une base de données SQLite dans un script PERL CGI qui est accessible par dbd :: sqlite . Ceci est en cours d'exécution en tant que CGI droit sur Apache.
La connexion DBI fonctionne bien et que les sélectionnent peuvent être exécutées. Cependant, lorsque j'essaie de faire un insert, je reçois un matrice avec l'erreur suivante: p>
DBD::SQLite::st execute failed: unable to open database file(1) at dbdimp.c line 402 at index.cgi line 66
5 Réponses :
SQLITE verrouille momentanément le fichier entier lorsqu'il effectue des insertions et des mises à jour (il n'y a pas de verrouillage de niveau record en tant que tel). Êtes-vous sûr que vous libérez les serrures?
La littérature SQLite vous recommande de démarrer une transaction, de collecter tous vos inserts et mises à jour du jour dans cette transaction, puis commettre. Cela évite de nombreux serrures de fichiers successifs et améliore les performances.
On dirait que le répertoire a besoin d'une autorisation d'écriture, la raison est la suivante:
SQLITE doit pouvoir créer un fichier de journal dans le même répertoire que la DB, avant que toutes les modifications puissent avoir lieu. Le journal est utilisé pour supporter la restauration de la transaction.
de: semble avoir besoin d'une autorisation d'écriture sur le répertoire parent de DB < / a>
Puisque SQLite verrouille tout le fichier de base de données, vous souhaiterez peut-être utiliser un mécanisme de tentative à base d'horaire. Je travaillais à peu près le même problème lorsque j'ai posé cette question sur ce lien associé question .
J'ai fini par écrire quelque chose de similaire à Mark Fowler's Tentative qui tente si l'exception projetée par le sous correspond à une expression régulière, dans mon cas:
Le chemin d'accès au répertoire dans lequel réside le fichier DB doit avoir un ensemble de bits exécutables et d'écriture, afin d'y accéder à partir du script.
En outre, si vous ne voulez pas le fichier db Pour être consulté directement (même sans l'utilisation de fichiers de serveur spéciaux), il devrait avoir des autorisations d'accès telles que 600 et si le répertoire contenant ne doit pas être consulté directement (à nouveau, même sans l'utilisation de fichiers de serveur spéciaux), il devrait avoir des autorisations d'accès. tels que 700.
J'utilise cette configuration et cela fonctionne bien à la fois localement et sur le serveur où j'espère mon site.
Bien entendu, l'autorisation du répertoire contenant ne peut pas Soyez 700 s'il existe un autre fichier à l'intérieur qui doit être accessible via HTML, CSS ou JavaScript. Il devrait être 755 à la place.
Si vous ne voulez pas définir des autorisations d'écriture sur l'ensemble du répertoire, comme expliqué dans la réponse de Todd Hunter, vous pouvez plutôt définir le journal_mode code> pragma à "mémoire".
Dans ce cas, méfiez-vous: P>
Le mode de journalisation de la mémoire stocke le journal de restauration en volatils RAM. Cela permet d'économiser des E / S du disque mais au détriment de la sécurité de la base de données et intégrité. Si l'application utilisant SQLite se bloque au milieu d'une transaction lorsque le mode de journalisation de la mémoire est défini, la base de données Le fichier sera très probablement corrompu. p> BlockQuote>
Donc, si c'est une bonne solution dépend de votre base de données et de la manière dont elle est utilisée. p>
d'autres personnes mentionnent également le temp_store pragma . Je n'avais pas besoin de définir cela, mais cela peut dépendre de la manière dont la base de données est utilisée. P>
Donc, dans votre script Perl CGI, vous pouvez essayer ceci: p>
$dbh->do("PRAGMA journal_mode = MEMORY"); $dbh->do("PRAGMA temp_store = MEMORY");
Pouvez-vous définir temporairement le répertoire et la permission de fichier sur 777 et de la revérifier?
Ah ha! Changer les autorisations de répertoire à 777 corrigé cela. Savez-vous pourquoi c'est?
Vous avez probablement oublié de définir la permission de la bonne annuaire aussi.