SQLiteデータベースモードを読み取り/書き込みに変更する

SQLiteデータベースを読み取り専用から読み取り/書き込みに変更するにはどうすればよいですか？

私が更新ステートメントを実行したとき、私は常に得ました：

SQLエラー：読み取り専用データベースに書き込もうとしました

SQLiteファイルは、ファイルシステム上の書き込み可能なファイルです。

このエラーメッセージにはいくつかの理由が考えられます。

• 複数のプロセスが同時にデータベースを開いています（FAQを参照）。

• データベースを圧縮して暗号化するプラグインがあります。DBを変更することはできません。

• 最後に、別のFAQには、「データベースファイルを含むディレクトリが、CGIスクリプトを実行するユーザーにも書き込み可能であることを確認してください」と記載されています。これは、エンジンがディレクトリにさらにファイルを作成する必要があるためだと思います。

• クラッシュ後など、ファイルシステム全体が読み取り専用になる場合があります。

• Unixシステムでは、別のプロセスがファイル全体を置き換えることができます。

/ db dir上のすべてのファイルの所有者をrootから私に変更することで、これを解決しました。

ls -lそのフォルダーで行うだけです。ファイラーのいずれかが所有者である場合は、root次のように使用して変更します。sudo chown user file

このエラーは通常、データベースがすでに1つのアプリケーションによってアクセスされており、別のアプリケーションでアクセスしようとしたときに発生します。

Androidを使用している場合。

に書き込み権限を追加したことを確認EXTERNAL_STORAGEしてくださいAndroidManifest.xml。

この行をAndroidManifest.xmlファイルの<application>タグの外側に追加します。

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

これにより、アプリケーションがSDカードに書き込むことができます。これはEXTERNAL_STORAGE、データベースをデバイスに保存した場所にある場合に役立ちます。

Linuxコマンドシェルでは、次のようにしました。

chmod 777 <db_folder>

データベースファイルが含まれる場所。

できます。これでデータベースにアクセスして挿入クエリを実行できます。

（このエラーメッセージは通常、誤解を招くものであり、通常は一般的な権限エラーです）

Windowsの場合

• データベースに対して直接SQLを発行する場合は、SQLの実行に使用しているアプリケーションが管理者として実行されていることを確認してください。
• アプリケーションが更新を試行している場合、アプリケーションがデータベースにアクセスするために使用するアカウントには、データベースファイルを含むフォルダーに対するアクセス許可が必要な場合があります。たとえば、IISがデータベースにアクセスしている場合、IUSRとIIS_IUSRSの両方に適切なアクセス許可が必要な場合があります（これらのアカウントに一時的にフォルダーのフルコントロールを与え、これが機能するかどうかを確認して、適切なアクセス許可を設定することで、これを試すことができます）。

今日もこの問題がありました。

これは、Windows MobileのActiveSyncが原因でした-私が作業していたフォルダーが同期されたため、ASプロセスがDBファイルを時々取得し、このエラーが発生しました。

Linuxでは、データベースファイルを含むフォルダ全体に読み取り/書き込み権限を付与します。

また、SELinuxが書き込みをブロックしている可能性もあります。正しい権限を設定する必要があります。

私のSELinux管理GUI（Fedora 19上）で、httpd_unified（すべてのコンテンツファイルのHTTPD処理を統一する）というラベルの付いた行のボックスをチェックしました。

個人的な経験を共有するために、最終的に両方を修正するこのエラーに遭遇しました。必ずしも問題に関連しているとは限りませんが、このエラーは非常に一般的であり、膨大な数の原因が考えられます。

1. 別のアプリケーションでデータベースインスタンスが開いています。私のDBは「ロックされた」状態にあるため、読み取り専用モードに移行しています。DBを共有しているアプリケーションの2番目のインスタンスを停止することで、それを追跡できました。

2. ディレクトリツリーの権限-ユーザーアカウントに、ファイルレベルだけでなく、/レベルまでの上位ディレクトリレベル全体の権限があることを確認してください。

ありがとう

Ubuntuでは、所有者をApacheグループに変更し、適切な権限を付与します（いいえ、777ではありません）。

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

更新

グループとユーザーの権限も設定できます。

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

コマンドラインから、データベースファイルが置かれているフォルダーを入力し、次のコマンドを実行します。

chmod 777 databasefilename

これにより、すべてのユーザーにすべての権限が付与されます。

Windowsの場合：

tl; dr：ファイルをもう一度開いてみてください。

私たちのシステムはこの問題に苦しんでおり、プログラム自体はほとんどの場合多くのスレッドから書き込み可能としてデータベースを開くことができるため、アクセス許可の問題ではありませんでしたが、時々（OSXではなくWindowsでのみ）、プログラム内の他のすべてのスレッドに問題がなくても、スレッドはこれらのエラーを受け取ります。

最終的に、失敗したスレッドは、別のスレッドがデータベースを閉じた直後（3ミリ秒以内）にデータベースを開こうとしたスレッドのみであることがわかりました。この問題は、Windows（またはWindowsでのsqliteの実装）がファイルを閉じたときに常にファイルリソースをすぐにクリーンアップするとは限らないためであると推測しました。これを回避するには、データベースを開くときにテスト書き込みクエリを実行します（たとえば、テーブルを作成してから、愚かな名前でドロップします）。作成/ドロップが失敗した場合、50ミリ秒待ってから再試行し、成功するか5秒が経過するまで繰り返します。

出来た; 明らかに、リソースがディスクにフラッシュするのに十分な時間が必要だっただけです。

DBの編集：データベースの編集で問題が発生しました。 ルートでない限り、私は
sudo chown 'non root username' ts3server.sqlitedb をsudo する必要
がありました。ファイルを編集できました。ユーザー名は、私の非rootアカウントのユーザー名です。

TeamSpeakの自動起動：非rootアカウントとして
crontab -e
@reboot / ts3server / path / aka /ts3server/ts3server_startscript.sh startへのパス

プロジェクトパスでTerminal django_project＃

sudo chown django:django *