Changer le mode de base de données SQLite en lecture-écriture

Comment puis-je changer une base de données SQLite de lecture seule à lecture-écriture?

Lorsque j'ai exécuté l'instruction de mise à jour, j'ai toujours:

Erreur SQL: tentative d'écriture d'une base de données en lecture seule

Le fichier SQLite est un fichier inscriptible sur le système de fichiers.

Il peut y avoir plusieurs raisons à ce message d'erreur:

• Plusieurs processus ont la base de données ouverte en même temps ( voir la FAQ ).

• Il existe un plugin pour compresser et crypter la base de données. Il ne permet pas de modifier la base de données.

• Enfin, une autre FAQ dit: "Assurez-vous que le répertoire contenant le fichier de base de données est également accessible en écriture à l'utilisateur exécutant le script CGI." Je pense que c'est parce que le moteur doit créer plus de fichiers dans le répertoire.

• L'ensemble du système de fichiers peut être en lecture seule, par exemple après une panne.

• Sur les systèmes Unix, un autre processus peut remplacer le fichier entier.

J'ai résolu cela en changeant de propriétaire de root à moi sur tous les fichiers sur / db dir.

Faites simplement ls -lsur ce dossier, si l'un des fichiers appartient rootà vous, modifiez-le simplement en utilisant:sudo chown user file

Cette erreur se produit généralement lorsque votre base de données est déjà accédée par une application et que vous essayez d'y accéder avec une autre application.

Si vous utilisez Android.

Assurez-vous d'avoir ajouté l'autorisation d'écrire EXTERNAL_STORAGEà votreAndroidManifest.xml .

Ajoutez cette ligne à votre AndroidManifest.xmlfichier au-dessus et en dehors de votre <application>balise.

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

Cela permettra à votre application d'écrire sur la carte SD. Cela vous aidera si vous EXTERNAL_STORAGEêtes là où vous avez stocké votre base de données sur l'appareil.

Dans le shell de commande Linux, j'ai fait:

chmod 777 <db_folder>

Où contient le fichier de base de données.

Ça marche. Je peux maintenant accéder à ma base de données et effectuer des requêtes d'insertion.

(ce message d'erreur est généralement trompeur et est généralement une erreur d'autorisation générale)

Sous Windows

• Si vous émettez du SQL directement sur la base de données, assurez-vous que l'application que vous utilisez pour exécuter le SQL s'exécute en tant qu'administrateur
• Si une application tente la mise à jour, le compte qu'elle utilise pour accéder à la base de données peut avoir besoin d'autorisations sur le dossier contenant votre fichier de base de données. Par exemple, si IIS accède à la base de données, l'IUSR et IIS_IUSRS peuvent tous deux avoir besoin des autorisations appropriées (vous pouvez essayer cela en donnant temporairement à ces comptes un contrôle total sur le dossier, en vérifiant si cela fonctionne, puis en attachant les autorisations le cas échéant)

J'ai aussi eu ce problème aujourd'hui.

Cela a été causé par ActiveSync sur Windows Mobile - le dossier dans lequel je travaillais a été synchronisé, de sorte que le processus AS a saisi le fichier DB de temps en temps, provoquant cette erreur.

À partir de la ligne de commande, entrez le dossier dans lequel se trouve votre fichier de base de données et exécutez la commande suivante:

chmod 777 databasefilename

Cela accordera toutes les autorisations à tous les utilisateurs.

Sous Linux, accordez des autorisations de lecture / écriture à tout le dossier contenant le fichier de base de données.

De plus, SELinux peut bloquer l'écriture. Vous devez définir les autorisations appropriées.

Dans mon GUI de gestion SELinux (sur Fedora 19), j'ai coché la case sur la ligne intitulée httpd_unified (Unify HTTPD gestion de tous les fichiers de contenu), et j'étais prêt à partir.

Sous Windows:

tl; dr: Essayez à nouveau d'ouvrir le fichier.

Notre système souffrait de ce problème, et ce n'était certainement pas un problème d'autorisations, car le programme lui-même serait capable d'ouvrir la base de données en écriture à partir de nombreux threads la plupart du temps, mais occasionnellement (uniquement sur Windows, pas sur OSX), un thread obtiendrait ces erreurs même si tous les autres threads du programme n'avaient aucune difficulté.

Nous avons finalement découvert que les threads qui échouaient étaient uniquement ceux qui essayaient d'ouvrir la base de données immédiatement après qu'un autre thread l'ait fermée (dans les 3 ms). Nous avons émis l'hypothèse que le problème était dû au fait que Windows (ou l'implémentation sqlite sous Windows) ne nettoie pas toujours immédiatement les ressources d'un fichier lors de la fermeture d'un fichier. Nous avons contourné cela en exécutant une requête d'écriture de test sur la base de données lors de l'ouverture (par exemple, en créant puis en supprimant une table avec un nom idiot). Si la création / suppression a échoué, nous avons attendu 50 ms et essayé à nouveau, en répétant jusqu'à ce que nous réussissions ou que 5 secondes se soient écoulées.

Ça a marché; apparemment, il fallait juste assez de temps pour que les ressources soient vidées sur le disque.

Pour partager l'expérience personnelle que j'ai rencontrée avec cette erreur qui a finalement corrigé les deux. Peut-être pas nécessairement lié à votre problème, mais il semble que cette erreur soit si générique qu'elle peut être attribuée à des milliards de choses.

1. Instance de base de données ouverte dans une autre application. Ma base de données semblait avoir été dans un état "verrouillé", donc elle passe en mode lecture seule. J'ai pu le retrouver en arrêtant la deuxième instance de l'application partageant la base de données.

2. Autorisation de l'arborescence de répertoires - assurez-vous de vous assurer que le compte utilisateur a l'autorisation non seulement au niveau du fichier, mais au niveau du répertoire supérieur tout entier jusqu'au niveau /.

Merci

Sur Ubuntu, changez le propriétaire du groupe Apache et accordez les bonnes autorisations (non, ce n'est pas 777):

sudo chgrp www-data <path to db.sqlite3>
sudo chmod 664 <path to db.sqlite3>

Mettre à jour

Vous pouvez également définir les autorisations pour le groupe et l' utilisateur .

sudo chown www-data:www-data <path to db.sqlite3>

Modifier la base de données: j'avais des problèmes pour modifier la base de données. J'ai fini par avoir à
sudo chown 'nom d'utilisateur non root' ts3server.sqlitedb
tant qu'il n'était pas root, je pouvais éditer le fichier. Le nom d'utilisateur est le nom d'utilisateur de mon compte non root.

Démarrage automatique de TeamSpeak: en tant que votre compte non root
crontab -e
@reboot / chemin vers ts3server / aka /home/ts3server/ts3server_startscript.sh start

Dans le chemin du projet Terminal django_project #

sudo chown django:django *