Zmień tryb bazy danych SQLite na odczyt i zapis

Jak mogę zmienić bazę danych SQLite z tylko do odczytu na do odczytu i zapisu?

Kiedy wykonałem instrukcję aktualizacji, zawsze otrzymywałem:

Błąd SQL: próba zapisu bazy danych tylko do odczytu

Plik SQLite jest zapisywalnym plikiem w systemie plików.

Przyczyn tego komunikatu o błędzie może być kilka:

• Baza danych jest otwarta w kilku procesach w tym samym czasie ( patrz FAQ ).

• Istnieje wtyczka do kompresji i szyfrowania bazy danych. Nie pozwala na modyfikację bazy danych.

• Na koniec inny często zadawane pytania mówi: „Upewnij się, że katalog zawierający plik bazy danych jest również zapisywalny dla użytkownika wykonującego skrypt CGI”. Myślę, że dzieje się tak, ponieważ silnik musi utworzyć więcej plików w katalogu.

• Cały system plików może być tylko do odczytu, na przykład po awarii.

• W systemach uniksowych inny proces może zastąpić cały plik.

Rozwiązałem ten problem, zmieniając właściciela z roota na mnie we wszystkich plikach w katalogu / db dir.

Po prostu zrób ls -lna tym folderze, jeśli którykolwiek z plików jest własnością, po rootprostu zmień go na siebie, używając:sudo chown user file

Ten błąd zwykle występuje, gdy jedna aplikacja korzysta już z bazy danych i próbujesz uzyskać do niej dostęp za pomocą innej aplikacji.

Jeśli używasz Androida.

Upewnij się, że dodałeś uprawnienia do pisania EXTERNAL_STORAGEdo swojego AndroidManifest.xml.

Dodaj tę linię do AndroidManifest.xmlpliku powyżej i poza <application>tagiem.

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

Umożliwi to Twojej aplikacji zapis na karcie SD. Pomoże to, jeśli w Twoim EXTERNAL_STORAGEmiejscu zapisałeś swoją bazę danych na urządzeniu.

W powłoce poleceń Linuksa:

chmod 777 <db_folder>

Gdzie zawiera plik bazy danych.

To działa. Teraz mogę uzyskać dostęp do mojej bazy danych i tworzyć zapytania.

(ten komunikat o błędzie jest zwykle mylący i jest zwykle ogólnym błędem dotyczącym uprawnień)

W systemie Windows

• Jeśli wydajesz SQL bezpośrednio w bazie danych, upewnij się, że aplikacja, której używasz do uruchamiania SQL, działa jako administrator
• Jeśli aplikacja podejmuje próbę aktualizacji, konto, którego używa do uzyskiwania dostępu do bazy danych, może wymagać uprawnień do folderu zawierającego plik bazy danych. Na przykład, jeśli IIS uzyskuje dostęp do bazy danych, zarówno IUSR, jak i IIS_IUSRS mogą wymagać odpowiednich uprawnień (możesz spróbować, tymczasowo dając tym kontom pełną kontrolę nad folderem, sprawdzając, czy to działa, a następnie wiążąc odpowiednie uprawnienia)

Ja też dzisiaj miałem ten problem.

Było to spowodowane przez ActiveSync w Windows Mobile - folder, w którym pracowałem, został zsynchronizowany, więc proces AS od czasu do czasu przechwytywał plik DB, powodując ten błąd.

W systemie Linux nadaj uprawnienia do odczytu / zapisu do całego folderu zawierającego plik bazy danych.

Ponadto SELinux może blokować zapis. Musisz ustawić odpowiednie uprawnienia.

W moim SELinuksie Management GUI (w Fedorze 19), zaznaczyłem pole w linii oznaczonej httpd_unified (Ujednolicona obsługa HTTPD wszystkich plików zawartości) i było dobrze.

W systemie Windows:

tl; dr: spróbuj ponownie otworzyć plik.

Nasz system cierpiał na ten problem i na pewno nie był to problem z uprawnieniami, ponieważ sam program byłby w stanie otworzyć bazę danych jako zapisywalną z wielu wątków przez większość czasu, ale czasami (tylko w systemie Windows, a nie na OSX), wątek otrzymywałby te błędy, mimo że wszystkie inne wątki w programie nie miały żadnych problemów.

W końcu odkryliśmy, że wątki, które kończyły się niepowodzeniem, to tylko te, które próbowały otworzyć bazę danych natychmiast po jej zamknięciu przez inny wątek (w ciągu 3 ms). Spekulowaliśmy, że problem wynikał z faktu, że system Windows (lub implementacja sqlite pod Windows) nie zawsze od razu czyści zasoby plików po zamknięciu pliku. Rozwiązaliśmy ten problem, uruchamiając zapytanie testowe do bazy danych podczas otwierania (np. Tworząc, a następnie usuwając tabelę o głupiej nazwie). Jeśli tworzenie / upuszczanie nie powiodło się, czekaliśmy 50 ms i próbowaliśmy ponownie, powtarzając, aż się powiedzie lub upłynęło 5 sekund.

Zadziałało; najwyraźniej wystarczyło wystarczająco dużo czasu, aby zasoby zostały przepuszczone na dysk.

Aby podzielić się osobistym doświadczeniem, napotkałem ten błąd, który ostatecznie naprawił oba. Może niekoniecznie być związany z twoim problemem, ale wygląda na to, że ten błąd jest tak ogólny, że można go przypisać miliardom rzeczy.

1. Instancja bazy danych otwarta w innej aplikacji. Moja baza danych wydawała się być w stanie „zablokowanym”, więc przechodzi w tryb tylko do odczytu. Udało mi się to wyśledzić, zatrzymując drugą instancję aplikacji udostępniającej bazę danych.

2. Uprawnienia do drzewa katalogów - upewnij się, że konto użytkownika ma uprawnienia nie tylko na poziomie pliku, ale na całym wyższym poziomie katalogu, aż do poziomu /.

Dzięki

Na Ubuntu zmień właściciela na grupę Apache i nadaj odpowiednie uprawnienia (nie, to nie jest 777):

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

Aktualizacja

Możesz także ustawić uprawnienia dla grupy i użytkownika .

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

W wierszu poleceń wprowadź folder, w którym znajduje się plik bazy danych, i wykonaj następujące polecenie:

chmod 777 databasefilename

Spowoduje to przyznanie wszystkich uprawnień wszystkim użytkownikom.

Edytuj bazę danych: miałem problemy z edycją bazy danych. Skończyło się na tym, że musiałem
sudo chown `` nazwa użytkownika innego niż root '' ts3server.sqlitedb,
o ile nie był to root, mogłem edytować plik. Nazwa użytkownika to nazwa użytkownika mojego konta innego niż root.

Auto start TeamSpeak: jako konto użytkownika innego niż root
crontab -e
@reboot / path to ts3server / aka /home/ts3server/ts3server_startscript.sh start

W ścieżce projektu Terminal django_project #

sudo chown django:django *