Изменение режима базы данных SQLite для чтения-записи

Ответ 1

Это сообщение об ошибке может иметь несколько причин:

• В нескольких процессах база данных открыта одновременно (см. FAQ).

• Есть плагин для сжатия и шифрования базы данных. Это не позволяет изменять БД.

• Наконец, в другом FAQ говорится: "Убедитесь, что каталог, содержащий файл базы данных, также доступен для записи пользователю, выполняющему сценарий CGI". Я думаю, это потому, что движок должен создавать больше файлов в каталоге.

• Вся файловая система может быть доступна только для чтения, например, после сбоя.

• В системах Unix другой процесс может заменить весь файл.

Ответ 2

Я решил это, изменив владельца от root ко мне на все файлы в каталоге db. db.

Просто сделайте ls -l в этой папке, если какой-либо из файлов принадлежит root, просто измените его на вас, используя: sudo chown user file

Ответ 3

При использовании Android.

Убедитесь, что вы добавили разрешение на запись в EXTERNAL_STORAGE на ваш AndroidManifest.xml.

Добавьте эту строку в ваш AndroidManifest.xml файл выше и вне вашего тега <application>.

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

Это позволит вашему приложению писать на SD-карту. Это поможет, если ваш EXTERNAL_STORAGE - это место, где вы сохранили свою базу данных на устройстве.

Ответ 4

Эта ошибка обычно возникает, когда к вашей базе данных уже обращается одно приложение, и вы пытаетесь получить к ней доступ с помощью другого приложения.

Ответ 5

У меня была и эта проблема сегодня.

Это вызвано ActiveSync на Windows Mobile - папка, в которой я работал, была синхронизирована, поэтому процесс AS схватил файл DB время от времени, вызвав эту ошибку.

Ответ 6

В командной строке Linux я сделал:

chmod 777 <db_folder>

Где находится файл базы данных.

Это работает. Теперь я могу получить доступ к моей базе данных и вставить запросы.

Ответ 7

(это сообщение об ошибке обычно вводит в заблуждение и обычно является общей ошибкой прав доступа)

В Windows

• Если вы используете SQL непосредственно для базы данных, убедитесь, что приложение, которое вы используете для запуска SQL, работает от имени администратора
• Если приложение пытается выполнить обновление, учетной записи, используемой для доступа к базе данных, могут потребоваться разрешения для папки, содержащей файл вашей базы данных. Например, если IIS обращается к базе данных, IUSR и IIS_IUSRS могут оба требовать соответствующих разрешений (вы можете попробовать это, временно предоставив этим учетным записям полный контроль над папкой, проверив, работает ли это, затем связав разрешения соответствующим образом)

Ответ 8

В Linux дайте разрешения на чтение и запись для всей папки, содержащей файл базы данных.

Кроме того, SELinux может блокировать запись. Вы должны установить правильные разрешения.

В моем графическом интерфейсе SELinux (в Fedora 19) я проверил поле в строке с надписью httpd_unified (Унифицировать обработку HTTPD всех файлов содержимого), и мне было хорошо идти.

Ответ 9

Чтобы поделиться личным опытом, я столкнулся с этой ошибкой, которая в итоге исправила оба. Возможно, это не обязательно связано с вашей проблемой, но, похоже, эта ошибка настолько общая, что ее можно отнести к разным вещам.

1. Экземпляр базы данных открыт в другом приложении. Моя БД оказалась в заблокированном состоянии, поэтому она перешла в режим только для чтения. Мне удалось отследить его, остановив второй экземпляр приложения, совместно использующего базу данных.

2. Разрешение дерева каталогов - убедитесь, что у учетной записи пользователя есть разрешение не только на уровне файлов, но и на всем верхнем уровне каталогов вплоть до /level.

Спасибо

Ответ 10

В командной строке введите папку, в которой находится файл базы данных, и выполните следующую команду:

chmod 777 databasefilename

Это предоставит все разрешения всем пользователям.

Ответ 11

В Windows:

tl; dr: попробуйте снова открыть файл.

Наша система страдала этой проблемой, и это определенно не было проблемой разрешений, так как сама программа могла бы открывать базу данных как можно многократно записывать из многих потоков, но иногда (только на Windows, а не на OSX), поток получал бы эти ошибки, хотя все остальные потоки в программе не имели никаких трудностей.

В конце концов мы обнаружили, что нисходящие потоки были только те, которые пытались открыть базу данных сразу после того, как другой поток закрыл ее (в течение 3 мс). Мы предположили, что проблема связана с тем, что Windows (или реализация sqlite под окнами) не всегда сразу очищает файловые ресурсы после закрытия файла. Мы обошли это, запустив тестовый запрос записи к db при открытии (например, создав затем опустив таблицу с глупым именем). Если создание/падение не удалось, мы ждали 50 мс и повторили попытку, повторяя, пока не исполнились, или не прошло 5 секунд.

Это сработало; по-видимому, просто нужно было достаточно времени для ресурсов, чтобы вывести их на диск.

Ответ 12

В пути проекта Терминал django_project #

sudo chown django:django *

Ответ 13

Отредактируйте БД: у меня возникли проблемы с редактированием db. Я закончил с необходимостью  sudo chown 'non root username' ts3server.sqlitedb
пока он не был root, я мог бы отредактировать файл. Имя пользователя - это учетная запись моей учетной записи non root.

Автоматический запуск TeamSpeak: как ваша учетная запись без root

  crontab -e
@reboot/путь к ts3server/aka/home/ts3server/ts3server_startscript.sh start

Ответ 14

В 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>