Cambia la modalità del database SQLite in lettura-scrittura

Come posso modificare un database SQLite da sola lettura a lettura-scrittura?

Quando ho eseguito l'istruzione di aggiornamento, ho sempre ottenuto:

Errore SQL: tentativo di scrivere un database di sola lettura

Il file SQLite è un file scrivibile sul filesystem.

Ci possono essere diversi motivi per questo messaggio di errore:

• Diversi processi hanno il database aperto contemporaneamente ( vedere le FAQ ).

• C'è un plugin per comprimere e crittografare il database. Non permette di modificare il DB.

• Infine, un'altra FAQ dice: "Assicurati che la directory contenente il file di database sia scrivibile anche per l'utente che esegue lo script CGI." Penso che ciò sia dovuto al fatto che il motore deve creare più file nella directory.

• L'intero filesystem potrebbe essere di sola lettura, ad esempio dopo un crash.

• Su sistemi Unix, un altro processo può sostituire l'intero file.

Ho risolto questo problema cambiando proprietario da root a me su tutti i file nella directory / db.

Basta farlo ls -lsu quella cartella, se uno qualsiasi dei filer è di proprietà, rootcambiarlo con te, usando:sudo chown user file

Questo errore di solito si verifica quando al tuo database accede già un'applicazione e stai tentando di accedervi con un'altra applicazione.

Se utilizzi Android.

Assicurati di aver aggiunto il permesso di scrivere al tuo EXTERNAL_STORAGEal tuo AndroidManifest.xml.

Aggiungi questa riga al tuo AndroidManifest.xmlfile sopra e fuori dal <application>tag.

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

Ciò consentirà alla tua applicazione di scrivere sulla scheda SD. Questo ti aiuterà se sei EXTERNAL_STORAGEdove hai archiviato il tuo database sul dispositivo.

Nella shell dei comandi di Linux, ho fatto:

chmod 777 <db_folder>

Dove contiene il file di database.

Funziona. Ora posso accedere al mio database ed eseguire query di inserimento.

(questo messaggio di errore è in genere fuorviante e di solito è un errore di autorizzazioni generali)

Su Windows

• Se stai emettendo SQL direttamente sul database, assicurati che qualsiasi applicazione che stai utilizzando per eseguire SQL sia in esecuzione come amministratore
• Se un'applicazione sta tentando l'aggiornamento, l'account che utilizza per accedere al database potrebbe richiedere le autorizzazioni per la cartella contenente il file del database. Ad esempio, se IIS sta accedendo al database, IUSR e IIS_IUSRS potrebbero entrambi necessitare delle autorizzazioni appropriate (puoi provare questo dando temporaneamente a questi account il pieno controllo sulla cartella, controllando se funziona, quindi vincolando le autorizzazioni come appropriato)

Anch'io oggi ho avuto questo problema.

È stato causato da ActiveSync su Windows Mobile: la cartella in cui stavo lavorando è stata sincronizzata, quindi il processo AS ha afferrato il file DB di volta in volta causando questo errore.

Dalla riga di comando, inserisci la cartella in cui si trova il tuo file di database ed esegui il seguente comando:

chmod 777 databasefilename

Ciò garantirà tutte le autorizzazioni a tutti gli utenti.

In Linux, concedere autorizzazioni di lettura / scrittura all'intera cartella contenente il file di database.

Inoltre, SELinux potrebbe bloccare la scrittura. È necessario impostare le autorizzazioni corrette.

Nella mia SELinux Management GUI (su Fedora 19), ho spuntato la casella sulla riga denominata httpd_unified (Unify HTTPD handling of all content files), ed ero a posto.

Su Windows:

tl; dr: prova ad aprire di nuovo il file.

Il nostro sistema soffriva di questo problema e sicuramente non era un problema di autorizzazioni, poiché il programma stesso sarebbe stato in grado di aprire il database come scrivibile da molti thread la maggior parte del tempo, ma occasionalmente (solo su Windows, non su OSX), un thread avrebbe ricevuto questi errori anche se tutti gli altri thread nel programma non avevano difficoltà.

Alla fine abbiamo scoperto che i thread che stavano fallendo erano solo quelli che stavano tentando di aprire il database immediatamente dopo che un altro thread lo aveva chiuso (entro 3 ms). Abbiamo ipotizzato che il problema fosse dovuto al fatto che Windows (o l'implementazione di sqlite in Windows) non sempre pulisce immediatamente le risorse dei file alla chiusura di un file. Abbiamo aggirato questo problema eseguendo una query di scrittura di prova sul database all'apertura (ad esempio, creando e poi rilasciando una tabella con un nome sciocco). Se la creazione / rilascio non è riuscita, abbiamo aspettato 50 ms e riprovato, ripetendo fino a quando non siamo riusciti o sono trascorsi 5 secondi.

Ha funzionato; apparentemente ci voleva solo tempo sufficiente per scaricare le risorse su disco.

Per condividere l'esperienza personale ho riscontrato questo errore che alla fine risolve entrambi. Potrebbe non essere necessariamente correlato al tuo problema, ma sembra che questo errore sia così generico che può essere attribuito a miliardi di cose.

1. Istanza di database aperta in un'altra applicazione. Il mio DB sembrava essere in uno stato "bloccato", quindi è passato alla modalità di sola lettura. Sono stato in grado di rintracciarlo arrestando la seconda istanza dell'applicazione che condivide il DB.

2. Autorizzazione albero di directory: assicurati che l'account utente disponga dell'autorizzazione non solo a livello di file ma a livello dell'intera directory superiore fino al livello /.

Grazie

Su Ubuntu, cambia il proprietario nel gruppo Apache e concedi le autorizzazioni corrette (no, non è 777):

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

Aggiornare

Puoi anche impostare le autorizzazioni per gruppo e utente .

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

Modifica il DB: avevo problemi a modificare il db. Ho finito per dover
sudo chown 'nome utente non root' ts3server.sqlitedb
fintanto che non era root, potevo modificare il file. Il nome utente è il nome utente del mio account non root.

Avvia automaticamente TeamSpeak: come account non root
crontab -e
@reboot / path to ts3server / aka /home/ts3server/ts3server_startscript.sh inizia

Nel percorso del progetto Terminal django_project #

sudo chown django:django *