Alterar o modo de banco de dados SQLite para leitura e gravação

Como posso alterar um banco de dados SQLite de somente leitura para leitura e gravação?

Quando executei a instrução de atualização, sempre obtive:

Erro de SQL: tentativa de escrever um banco de dados somente leitura

O arquivo SQLite é um arquivo gravável no sistema de arquivos.

Pode haver vários motivos para essa mensagem de erro:

• Vários processos têm o banco de dados aberto ao mesmo tempo ( consulte o FAQ ).

• Existe um plugin para compactar e criptografar o banco de dados. Não permite modificar o DB.

• Por último, outro FAQ diz: "Certifique-se de que o diretório que contém o arquivo de banco de dados também possa ser gravado pelo usuário que está executando o script CGI." Acho que é porque o motor precisa criar mais arquivos no diretório.

• Todo o sistema de arquivos pode ser somente leitura, por exemplo, após um travamento.

• Em sistemas Unix, outro processo pode substituir todo o arquivo.

Resolvi isso mudando o proprietário do root para mim em todos os arquivos em / db dir.

Basta fazer ls -lnessa pasta, se algum dos arquivadores pertencer a, rootbasta alterá-lo para você, usando:sudo chown user file

Este erro geralmente ocorre quando seu banco de dados já é acessado por um aplicativo e você está tentando acessá-lo com outro aplicativo.

Se estiver usando Android.

Certifique-se de ter adicionado a permissão para escrever EXTERNAL_STORAGEem seu AndroidManifest.xml.

Adicione esta linha ao seu AndroidManifest.xmlarquivo acima e fora da sua <application>tag.

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

Isso permitirá que seu aplicativo grave no cartão SD. Isso ajudará se EXTERNAL_STORAGEfor onde você armazenou seu banco de dados no dispositivo.

No shell de comando do Linux, eu fiz:

chmod 777 <db_folder>

Onde contém o arquivo de banco de dados.

Funciona. Agora posso acessar meu banco de dados e fazer consultas de inserção.

(esta mensagem de erro é geralmente enganosa e geralmente é um erro de permissão geral)

No Windows

• Se você estiver emitindo SQL diretamente no banco de dados, certifique-se de que qualquer aplicativo que esteja usando para executar o SQL esteja sendo executado como administrador
• Se um aplicativo estiver tentando a atualização, a conta que ele usa para acessar o banco de dados pode precisar de permissões na pasta que contém o arquivo do banco de dados. Por exemplo, se o IIS estiver acessando o banco de dados, o IUSR e o IIS_IUSRS podem precisar de permissões apropriadas (você pode tentar fazer isso temporariamente dando a essas contas controle total sobre a pasta, verificando se funciona e, em seguida, vinculando as permissões conforme apropriado)

Eu tive esse problema hoje também.

Foi causado pelo ActiveSync no Windows Mobile - a pasta em que eu estava trabalhando foi sincronizada, portanto, o processo AS capturava o arquivo DB de vez em quando, causando esse erro.

No Linux, conceda permissões de leitura / gravação para toda a pasta que contém o arquivo de banco de dados.

Além disso, o SELinux pode estar bloqueando a gravação. Você precisa definir as permissões corretas.

Em meu SELinux Management GUI (no Fedora 19), eu marquei a caixa na linha rotulada httpd_unified (Unificar manipulação HTTPD de todos os arquivos de conteúdo) e estava pronto para prosseguir.

Para compartilhar experiências pessoais que encontrei com este erro que eventualmente consertar ambos. Pode não estar necessariamente relacionado ao seu problema, mas parece que esse erro é tão genérico que pode ser atribuído a zilhões de coisas.

1. Instância de banco de dados aberta em outro aplicativo. Meu banco de dados parecia estar em um estado "bloqueado", por isso fez a transição para o modo somente leitura. Consegui rastreá-lo interrompendo a segunda instância do aplicativo que compartilha o banco de dados.

2. Permissão da árvore de diretório - certifique-se de que a conta do usuário tenha permissão não apenas no nível do arquivo, mas em todo o nível do diretório superior até o nível /.

obrigado

No Ubuntu, mude o proprietário para o grupo Apache e conceda as permissões corretas (não, não é 777):

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

Atualizar

Você também pode definir as permissões para grupo e usuário .

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

Na linha de comando, insira a pasta onde seu arquivo de banco de dados está localizado e execute o seguinte comando:

chmod 777 databasefilename

Isso concederá todas as permissões a todos os usuários.

No Windows:

tl; dr: Tente abrir o arquivo novamente.

Nosso sistema estava sofrendo desse problema, e definitivamente não era um problema de permissões, já que o próprio programa seria capaz de abrir o banco de dados como gravável a partir de muitos threads na maioria das vezes, mas ocasionalmente (apenas no Windows, não no OSX), um encadeamento obteria esses erros mesmo que todos os outros encadeamentos no programa não estivessem tendo dificuldades.

Por fim, descobrimos que os encadeamentos que estavam falhando eram apenas aqueles que tentavam abrir o banco de dados imediatamente após o encerramento de outro encadeamento (dentro de 3 ms). Especulamos que o problema se devia ao fato de que o Windows (ou a implementação sqlite no Windows) nem sempre limpa imediatamente os recursos do arquivo ao fechar um arquivo. Conseguimos contornar isso executando uma consulta de gravação de teste no banco de dados ao abrir (por exemplo, criando e eliminando uma tabela com um nome bobo). Se a criação / eliminação falhou, esperamos por 50 ms e tentamos novamente, repetindo até que obtivéssemos sucesso ou 5 segundos se passassem.

Funcionou; aparentemente, só precisava haver tempo suficiente para que os recursos fossem transferidos para o disco.

Edite o banco de dados: Eu estava tendo problemas para editar o banco de dados. Acabei tendo que
sudo chown 'nome de usuário não root' ts3server.sqlitedb
, desde que não fosse root, eu poderia editar o arquivo. Nome de usuário é o nome de usuário da minha conta não root.

Iniciar TeamSpeak automaticamente: como sua conta não root
crontab -e
@reboot / caminho para ts3server / aka /home/ts3server/ts3server_startscript.sh start

No caminho do projeto Terminal django_project #

sudo chown django:django *