SQLite 데이터베이스 모드를 읽기-쓰기로 변경

SQLite 데이터베이스를 읽기 전용에서 읽기-쓰기로 변경하려면 어떻게해야합니까?

업데이트 문을 실행할 때 항상 다음을 얻었습니다.

SQL 오류 : 읽기 전용 데이터베이스 쓰기 시도

SQLite 파일은 파일 시스템에서 쓰기 가능한 파일입니다.

이 오류 메시지에는 여러 가지 이유가있을 수 있습니다.

• 여러 프로세스에서 동시에 데이터베이스를 엽니 다 ( FAQ 참조 ).

• 데이터베이스를 압축하고 암호화하는 플러그인이 있습니다. DB를 수정할 수 없습니다.

• 마지막으로, 또 다른 FAQ 는 "데이터베이스 파일이 포함 된 디렉토리가 CGI 스크립트를 실행하는 사용자도 쓸 수 있는지 확인하십시오."라고 말합니다. 엔진이 디렉토리에 더 많은 파일을 만들어야하기 때문이라고 생각합니다.

• 예를 들어 충돌 후 전체 파일 시스템이 읽기 전용 일 수 있습니다.

• Unix 시스템에서는 다른 프로세스가 전체 파일을 대체 할 수 있습니다.

/ db dir의 모든 파일에서 소유자를 루트에서 나로 변경하여이 문제를 해결했습니다.

그냥 할 ls -l파일러 중 하나가 소유하고있는 경우, 해당 폴더에 root그냥 당신로 변경, 사용 :sudo chown user file

이 오류는 일반적으로 이미 한 응용 프로그램에서 데이터베이스에 액세스하고 다른 응용 프로그램에서 액세스하려고 할 때 발생합니다.

Android를 사용하는 경우.

만들기 확실히 당신은 당신에 대한 쓰기 권한을 추가 한 EXTERNAL_STORAGE당신에 AndroidManifest.xml.

태그 AndroidManifest.xml위와 외부 에이 줄을 파일에 추가합니다 <application>.

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

이렇게하면 애플리케이션이 sdcard에 쓸 수 있습니다. 이것은 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. 디렉토리 트리 권한-사용자 계정이 파일 수준뿐만 아니라 전체 상위 디렉토리 수준에서 / 수준까지의 권한을 가지고 있는지 확인하십시오.

감사

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에서만) 데이터베이스를 열 수 있었기 때문에 확실히 권한 문제가 아니 었습니다. 프로그램의 다른 모든 스레드에 어려움이 없더라도 스레드는 이러한 오류를 받게됩니다.

결국 실패한 스레드는 다른 스레드가 데이터베이스를 닫은 직후 (3ms 이내) 데이터베이스를 열려고하는 스레드뿐이라는 사실을 발견했습니다. 우리는 Windows (또는 Windows의 sqlite 구현)가 파일을 닫을 때 파일 리소스를 즉시 정리하지 않기 때문에 문제가 발생했다고 추측했습니다. 열 때 db에 대해 테스트 쓰기 쿼리를 실행하여이 문제를 해결했습니다 (예 : 어리석은 이름으로 테이블을 만든 다음 삭제). 생성 / 삭제가 실패하면 50ms 동안 기다렸다가 다시 시도하여 성공하거나 5 초가 경과 할 때까지 반복합니다.

작동했습니다. 리소스가 디스크로 플러시되는 데 충분한 시간이 필요했습니다.

DB 편집 : DB를 편집하는 데 문제가있었습니다. 나는
루트가 아닌 한 '비 루트 사용자 이름'ts3server.sqlitedb 를 sudo
해야했고 파일을 편집 할 수있었습니다. 사용자 이름은 루트가 아닌 계정의 사용자 이름입니다.

TeamSpeak 자동 시작 : 루트가 아닌 계정으로
crontab -e
@reboot / path to ts3server / aka /home/ts3server/ts3server_startscript.sh start

프로젝트 경로 터미널 django_project #

sudo chown django:django *