Thay đổi chế độ cơ sở dữ liệu SQLite thành đọc-ghi

Làm cách nào để thay đổi cơ sở dữ liệu SQLite từ chỉ đọc sang đọc-ghi?

Khi tôi thực hiện câu lệnh cập nhật, tôi luôn nhận được:

Lỗi SQL: cố gắng viết cơ sở dữ liệu chỉ đọc

Tệp SQLite là một tệp có thể ghi trên hệ thống tệp.

Có thể có một số lý do cho thông báo lỗi này:

• Một số quy trình có cơ sở dữ liệu mở cùng một lúc ( xem Câu hỏi thường gặp ).

• Có một plugin để nén và mã hóa cơ sở dữ liệu. Nó không cho phép sửa đổi DB.

• Cuối cùng, một Câu hỏi thường gặp khác nói: "Đảm bảo rằng thư mục chứa tệp cơ sở dữ liệu cũng có thể ghi được đối với người dùng thực thi tập lệnh CGI." Tôi nghĩ điều này là do công cụ cần tạo thêm tệp trong thư mục.

• Toàn bộ hệ thống tệp có thể chỉ được đọc, chẳng hạn như sau khi gặp sự cố.

• Trên hệ thống Unix, một quy trình khác có thể thay thế toàn bộ tệp.

Tôi đã giải quyết vấn đề này bằng cách thay đổi chủ sở hữu từ người gốc thành tôi trên tất cả các tệp trên / db dir.

Chỉ cần thực hiện ls -ltrên thư mục đó, nếu bất kỳ bộ lọc nào thuộc sở hữu của rootbạn, chỉ cần thay đổi nó cho bạn, sử dụng:sudo chown user file

Lỗi này thường xảy ra khi cơ sở dữ liệu của bạn đã được một ứng dụng truy cập và bạn đang cố gắng truy cập nó bằng một ứng dụng khác.

Nếu sử dụng Android.

Đảm bảo rằng bạn đã thêm quyền để viết thư cho của EXTERNAL_STORAGEbạn AndroidManifest.xml.

Thêm dòng này vào AndroidManifest.xmltệp của bạn ở trên và bên ngoài <application>thẻ của bạn .

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

Điều này sẽ cho phép ứng dụng của bạn ghi vào sdcard. Điều này sẽ hữu ích nếu của bạn EXTERNAL_STORAGElà nơi bạn đã lưu trữ cơ sở dữ liệu của mình trên thiết bị.

Trong trình bao lệnh Linux, tôi đã làm:

chmod 777 <db_folder>

Nơi chứa tệp cơ sở dữ liệu.

Nó hoạt động. Bây giờ tôi có thể truy cập cơ sở dữ liệu của mình và thực hiện các truy vấn chèn.

(thông báo lỗi này thường gây hiểu lầm và thường là lỗi cấp phép chung)

Trên Windows

• Nếu bạn đang phát hành SQL trực tiếp với cơ sở dữ liệu, hãy đảm bảo rằng bất kỳ ứng dụng nào bạn đang sử dụng để chạy SQL đang chạy với tư cách quản trị viên
• Nếu một ứng dụng đang cố gắng cập nhật, tài khoản mà ứng dụng sử dụng để truy cập cơ sở dữ liệu có thể cần quyền trên thư mục chứa tệp cơ sở dữ liệu của bạn. Ví dụ: nếu IIS đang truy cập cơ sở dữ liệu, IUSR và IIS_IUSRS đều có thể cần các quyền thích hợp (bạn có thể thử điều này bằng cách tạm thời cấp cho các tài khoản này toàn quyền kiểm soát thư mục, kiểm tra xem điều này có hoạt động không, sau đó buộc các quyền lại nếu thích hợp)

Tôi cũng gặp vấn đề này hôm nay.

Đó là do ActiveSync trên Windows Mobile - thư mục tôi đang làm việc đã được đồng bộ hóa nên quá trình AS lấy tệp DB thỉnh thoảng gây ra lỗi này.

Trên Linux, cấp quyền đọc / ghi cho toàn bộ thư mục chứa tệp cơ sở dữ liệu.

Ngoài ra, SELinux có thể đang chặn việc ghi. Bạn cần đặt các quyền chính xác.

Trong GUI quản lý SELinux của tôi (trên Fedora 19), tôi đã chọn hộp trên dòng có nhãn httpd_unified (Hợp nhất xử lý HTTPD của tất cả các tệp nội dung) và tôi đã sẵn sàng.

Để chia sẻ kinh nghiệm cá nhân tôi gặp phải với lỗi này mà cuối cùng đã khắc phục được cả hai. Có thể không nhất thiết phải liên quan đến vấn đề của bạn nhưng có vẻ như lỗi này chung chung đến mức có thể được quy cho hàng triệu thứ.

1. Phiên bản cơ sở dữ liệu mở trong một ứng dụng khác. DB của tôi dường như đã ở trạng thái "bị khóa" nên nó chuyển sang chế độ chỉ đọc. Tôi đã có thể theo dõi nó bằng cách dừng phiên bản thứ 2 của ứng dụng chia sẻ DB.

2. Quyền của cây thư mục - hãy đảm bảo tài khoản người dùng có quyền không chỉ ở cấp tệp mà còn ở toàn bộ cấp thư mục trên theo cách đến / cấp.

Cảm ơn

Trên Ubuntu, thay đổi chủ sở hữu thành nhóm Apache và cấp quyền phù hợp (không, không phải là 777):

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

Cập nhật

Bạn cũng có thể đặt quyền cho nhóm và người dùng .

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

Từ dòng lệnh, hãy nhập thư mục chứa tệp cơ sở dữ liệu của bạn và thực hiện lệnh sau:

chmod 777 databasefilename

Điều này sẽ cấp tất cả các quyền cho tất cả người dùng.

Trên Windows:

tl; dr: Thử mở lại tệp.

Hệ thống của chúng tôi đang gặp sự cố này và chắc chắn không phải là vấn đề về quyền, vì bản thân chương trình sẽ có thể mở cơ sở dữ liệu dưới dạng có thể ghi từ nhiều luồng hầu hết thời gian, nhưng đôi khi (chỉ trên Windows, không phải trên OSX), một luồng sẽ gặp những lỗi này mặc dù tất cả các luồng khác trong chương trình không gặp khó khăn gì.

Cuối cùng chúng tôi phát hiện ra rằng các luồng bị lỗi chỉ là những luồng đang cố gắng mở cơ sở dữ liệu ngay lập tức sau khi một luồng khác đã đóng nó (trong vòng 3 ms). Chúng tôi suy đoán rằng vấn đề là do Windows (hoặc triển khai sqlite trong windows) không phải lúc nào cũng dọn dẹp tài nguyên tệp ngay lập tức khi đóng tệp. Chúng tôi đã giải quyết vấn đề này bằng cách chạy một truy vấn viết thử đối với db khi mở (ví dụ: tạo sau đó thả một bảng có tên ngớ ngẩn). Nếu tạo / thả không thành công, chúng tôi đợi 50 mili giây và thử lại, lặp lại cho đến khi thành công hoặc 5 giây trôi qua.

Nó đã làm việc; rõ ràng chỉ cần có đủ thời gian để tài nguyên được chuyển ra đĩa.

Chỉnh sửa DB: Tôi đã gặp sự cố khi chỉnh sửa db. Tôi đã kết thúc việc phải
sudo chown 'tên người dùng không phải root' ts3server.sqlitedb
miễn là nó không phải là root, tôi có thể chỉnh sửa tệp. Tên người dùng là tên người dùng của tài khoản không phải gốc của tôi.

Tự động khởi động TeamSpeak: khi tài khoản không phải gốc của bạn
crontab -e
@reboot / đường dẫn đến ts3server / aka /home/ts3server/ts3server_startscript.sh start

Trong đường dẫn dự án Terminal django_project #

sudo chown django:django *