Змініть режим бази даних SQLite на читання-запис

Як я можу змінити базу даних SQLite з "лише для читання" на "читання-запис"?

Коли я виконував оператор оновлення, я завжди отримував:

Помилка SQL: спроба написати лише базу даних для читання

Файл SQLite - це файл, що записується у файловій системі.

Причин цього повідомлення про помилку може бути кілька:

• Кілька процесів відкривають базу даних одночасно ( див. FAQ ).

• Існує плагін для стиснення та шифрування бази даних. Це не дозволяє змінювати БД.

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

• Уся файлова система може бути прочитана лише, наприклад, після збоїв.

• У системах Unix інший процес може замінити весь файл.

Я вирішив це, змінивши власника з root на всі файли в / 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 можуть потребувати відповідних дозволів (ви можете спробувати це, тимчасово надавши цим обліковим записам повний контроль над папкою, перевіривши, чи це працює, а потім привласнивши дозволи, якщо потрібно)

У мене ця проблема була і сьогодні.

Це було викликано ActiveSync на Windows Mobile - папка, в якій я працював, синхронізована, тому процес AS час від часу захоплював файл DB, викликаючи цю помилку.

У Linux надайте дозволи на читання / запис всій папці, що містить файл бази даних.

Також SELinux може блокувати запис. Потрібно встановити правильні дозволи.

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

Щоб поділитися особистим досвідом, я зіткнувся з цією помилкою, яка врешті виправить обоє. Можливо, це не обов'язково пов'язане з вашою проблемою, але, здається, ця помилка є настільки загальною, що її можна віднести до газильйонних речей.

1. Екземпляр бази даних відкривається в іншій програмі. Моя БД виявилася в "заблокованому" стані, тому вона перейшла в режим лише для читання. Мені вдалося відстежити це, зупинивши другий екземпляр програми, що ділиться БД.

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: спробуйте відкрити файл ще раз.

Наша система страждала від цієї проблеми, і вона, безумовно, не була проблемою дозволів, оскільки сама програма змогла б відкривати базу даних як записувану з багатьох потоків більшу частину часу, але періодично (лише для Windows, а не для OSX), нитка отримає ці помилки, хоча всі інші потоки в програмі не мали жодних труднощів.

Зрештою, ми виявили, що потоки, які вийшли з ладу, були лише тими, хто намагався відкрити базу даних відразу після того, як інший потік закрив її (протягом 3 мс). Ми припускали, що проблема пов’язана з тим, що Windows (або реалізація sqlite під Windows) не завжди відразу прибирає файлові ресурси після закриття файлу. Ми подолали це, запустивши тестовий запит на запитання проти db при відкритті (наприклад, створивши потім скидання таблиці з дурним іменем). Якщо створення / падіння не вдалося, ми зачекали 50 мс і спробували ще раз, повторюючи, поки ми не досягли успіху або пройшло 5 секунд.

Це спрацювало; Мабуть, просто потрібно було достатньо часу, щоб ресурси витікали на диск.

Редагування БД: У мене були проблеми з редагуванням db. Мені в кінцевому підсумку довелося отримати
sudo chown 'некорінне ім'я користувача' ts3server.sqlitedb
тих пір, поки це не було root, і я міг редагувати файл. Ім'я користувача - це ім’я мого некористувального облікового запису.

Автоматичний запуск TeamSpeak: як ваш кореневий обліковий запис
crontab -e
@reboot / шлях до ts3server / aka /home/ts3server/ts3server_startscript.sh start

На шляху проекту термінал django_project #

sudo chown django:django *