sqlite3 - studio - Cambiar el modo de base de datos SQLite a lectura-escritura
sqlite3 descargar (11)
¿Cómo puedo cambiar una base de datos SQLite de solo lectura a lectura-escritura?
Cuando ejecuté la declaración de actualización, siempre obtuve:
Error de SQL: intento de escribir una base de datos de solo lectura
El archivo SQLite es un archivo grabable en el sistema de archivos.
Puede haber varias razones para este mensaje de error:
Varios procesos tienen la base de datos abierta al mismo tiempo ( ver las preguntas frecuentes ).
Hay un complemento para comprimir y encriptar la base de datos. No permite modificar el DB.
Por último, otra pregunta frecuente dice: "Asegúrese de que el directorio que contiene el archivo de base de datos también se pueda escribir en el usuario que ejecuta el script CGI". Creo que esto se debe a que el motor necesita crear más archivos en el directorio.
Tuve este problema hoy, también.
Fue causada por ActiveSync en Windows Mobile. La carpeta en la que estaba trabajando se sincronizó, por lo que el proceso AS tomó el archivo DB de vez en cuando y causó este error.
Desde la línea de comando, ingrese la carpeta donde está ubicado su archivo de base de datos y ejecute el siguiente comando:
chmod 777 databasefilename
Esto otorgará todos los permisos a todos los usuarios.
Si usa Android.
Asegúrate de haber agregado el permiso para escribir en tu EXTERNAL_STORAGE en tu AndroidManifest.xml .
Agregue esta línea a su archivo AndroidManifest.xml arriba y fuera de su etiqueta <application> .
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
Esto permitirá que su aplicación escriba en la tarjeta SD. Esto ayudará si su EXTERNAL_STORAGE es donde ha almacenado su base de datos en el dispositivo.
Lo resolví cambiando el propietario de root a mí en todos los archivos en / db dir.
Solo haga ls -l en esa carpeta, si alguno de los archivos es propiedad de root simplemente cámbielo a usted, usando: sudo chown user file
En el shell de comandos de Linux, lo hice:
chmod 777 <db_folder>
Donde contiene el archivo de base de datos.
Funciona. Ahora puedo acceder a mi base de datos y hacer consultas de inserción.
Edite el DB: estaba teniendo problemas para editar el db. Terminé teniendo que
sudo chown ''nombre de usuario no root'' ts3server.sqlitedb
siempre que no sea root, podría editar el archivo. El nombre de usuario es el nombre de usuario de mi cuenta no root.
Inicio automático TeamSpeak: como su cuenta no root
crontab -e
@reboot / path to ts3server / aka /home/ts3server/ts3server_startscript.sh start
En Linux, conceda permisos de lectura / escritura a toda la carpeta que contiene el archivo de la base de datos.
Además, SELinux podría estar bloqueando la escritura. Debes establecer los permisos correctos.
En mi GUI de administración de SELinux (en Fedora 19), marqué la casilla en la línea etiquetada httpd_unified (Unificar el manejo HTTPD de todos los archivos de contenido), y estaba listo para continuar.
Este error generalmente ocurre cuando una aplicación ya accede a su base de datos y está intentando acceder a ella con otra base de datos.
En Ubuntu, cambie el propietario al grupo Apache y otorgue los permisos correctos (no, no es 777):
sudo chown :www-data <path to db.sqlite3>
sudo chown 664 <path to db.sqlite3>
En Windows:
tl; dr: intente abrir el archivo nuevamente.
Nuestro sistema sufría este problema, y ​​definitivamente no era un problema de permisos, ya que el programa en sí mismo podría abrir la base de datos como escribible desde muchos hilos la mayor parte del tiempo, pero ocasionalmente (solo en Windows, no en OSX), un hilo obtendría estos errores aunque todos los demás hilos del programa no tuvieran dificultades.
Finalmente descubrimos que los hilos que fallaban eran solo aquellos que intentaban abrir la base de datos inmediatamente después de que otro hilo la había cerrado (en 3 ms). Especulamos que el problema se debió al hecho de que Windows (o la implementación de sqlite en Windows) no siempre limpia inmediatamente los recursos de los archivos al cerrar un archivo. Lo solucionamos ejecutando una consulta de escritura de prueba contra el DB al abrirlo (por ejemplo, crear y luego colocar una tabla con un nombre tonto). Si la creación / caída falla, esperamos 50 ms y lo volvimos a intentar, repitiéndolo hasta que lo logramos o pasaron 5 segundos.
Funcionó; aparentemente solo necesitaba tiempo suficiente para que los recursos se vayan al disco.