Файлы sqlite можно ли удалять
Я создал базу данных sqlite программно со стандартным способом расширения SQLiteOpenHelper и замены onCreate() . Таким образом, база данных создается на лету, когда это необходимо.
Я хотел бы проверить содержимое файла db на моем компьютере с OS X с помощью браузера sqlite. Я знаю имя файла db, но не могу найти его на устройстве. Я подключился к устройству через USB и посмотрел с помощью Finder и терминала, но я просто не могу найти файл db.
Какое расположение по умолчанию для баз данных sqlite на устройстве Android?
Вы можете найти созданную вами базу данных с именем
Вытащите его с помощью File Explorer и переименуйте в расширение .db3, чтобы использовать его в SQLiteExplorer.
Используйте File Explorer DDMS, чтобы перейти в каталог эмулятора.
Когда я пробую это в эмуляторе, я могу перейти в / data. Но когда я пытаюсь это сделать с подключенным Galaxy Vibrant, я не могу выполнить cd в / data. В этих двух случаях сервер adb работает по-разному?
У вас нет доступа к папке / data на реальном телефоне. Это изменено 700 . Чтобы его увидеть, вам нужны права root.
На всякий случай, если вы хотите получить путь из приложения , это context.getDatabasePath (""). Что на самом деле возвращает путь, указанный выше. Вы можете получить доступ к этому пути для чтения и записи, но только из приложения, создавшего базу данных.
Для этого я сделал
И для этого ваше приложение должно иметь разрешение на доступ к SD-карте, добавьте следующий параметр в свой manifest.xml
Не блестящий способ, но работает.
если не работает . используйте имя базы данных "/data/data/your.app.package/databases/your_db" Просто удалите расширение ".db3"
Это решение отлично работает. Но вы можете использовать getDatabasePath (your_db_name) для получения объекта File и использовать getAbsolutePath () для получения точного пути вместо его построения. Метод getDatabasePath определен в ContextWrapper.
Контекст содержит множество функций пути: Context.getXXXPath ()
Одна из них - android.content.Context.getDatabasePath (String dbname), которая возвращает абсолютный путь к базе данных с именем dbname.
Возвращенный путь в этом случае будет примерно таким:
Обратите внимание, что этот путь создается автоматически при использовании SQLiteOpenHelper для открытия БД.
Если вы говорите о /data/data/ недоступном реальном устройстве . У вас должны быть root права .
Это не совсем так. Его нельзя просмотреть , но доступность файлов внутри зависит от их индивидуальных прав доступа.
@SreecharanDesabattula, вам нужно перейти в оболочку adb и переключиться на суперпользователя с помощью команды «su» для просмотра каталога.
Это старый вопрос, но ответ может помочь другим.
Путь по умолчанию, по которому Android сохраняет базы данных, нельзя использовать на некорневых устройствах. Итак, самый простой способ получить доступ к файлу базы данных (только для сред отладки) - изменить конструктор класса:
Не забудьте изменить производственную среду с помощью этих строк:
Мне так жаль. Этому ответу четыре года. И ОП старше этого (2010 г.). В настоящее время Android значительно отличается от 2010 года. Таким образом, база данных может располагаться по другому пути. Мне очень жаль, что я ничем не могу вам помочь.
База данных SQLite - это просто файл. Вы можете взять этот файл, переместить его и даже скопировать в другую систему (например, со своего телефона на рабочую станцию), и он будет работать нормально. Android сохраняет файл в /data/data/packagename/databases/ каталоге. Вы можете использовать adb command или File Explorer view в Eclipse ( Window > Show View > Other. > Android > File Explorer ) для просмотра, перемещения или удаления.
что ж, это может быть поздно, но это поможет. Вы можете получить доступ к базе данных без рутирования своего устройства через adb
запустите adb с помощью cmd и введите следующие команды
Теперь вы можете открыться отсюда.
Да, для отладочного APK. Нет, для производственной версии (или для версий Android, где не работает функция run-as).
Если вы назовете свою базу данных как файл без указания пути, тогда наиболее распространенный способ получить ее папку выглядит так:
где DBAdapter.DATABASE_NAME просто String "mydatabase.db".
Context.getFilesDir() возвращает путь к файлам приложения, например: /data/data//files/ вот почему вам нужно .getParent()+"/databases/" удалить «файлы» и вместо этого добавить «базы данных».
Кстати, Eclipse предупредит вас о жестко запрограммированной строке «data / data /», но не в этом случае.
И проверьте, хранится ли ваша база данных в хранилище устройства. Если это так, вы должны использовать разрешение в Manifest.xml:
Вы можете получить к нему доступ, используя инструкции по adb shell
Контент по ссылке выше:
Учебник: как получить доступ к базе данных Android с помощью командной строки. Когда вы начинаете работать с базой данных в своей программе, действительно важно и полезно иметь возможность обращаться к ней напрямую, вне вашей программы, для проверки того, что программа только что сделала, и для отладки.
И это важно еще и на Android.
Вот как это сделать:
1) Запустите эмулятор (или подключите реальное устройство к ПК). Обычно для этого я запускаю одну из своих программ из Eclipse. 2) Запустите командную строку в каталоге инструментов Android. 3) типа adb shell. Это запустит оболочку unix на вашем эмуляторе / подключенном устройстве. 4) перейдите в каталог, в котором находится ваша база данных: cd data / data здесь у вас есть список всех приложений на вашем устройстве. Войдите в каталог приложений (будьте осторожны, Unix чувствителен к регистру !!) cd com.alocaly.LetterGame и спуститесь. в каталоге ваших баз данных: cd databases Здесь вы можете найти все ваши базы данных. В моем случае есть только один (сейчас): SCORE_DB 5) Запустите sqlite в базе данных, которую вы хотите проверить / изменить: sqlite3 SCORE_DB Отсюда вы можете проверить, какие таблицы присутствуют: .tables 6) введите любую инструкцию SQL, которую хотите : выберите * из Score;
Это довольно просто, но каждый раз, когда мне это нужно, я не знаю, где это найти.
Если ваше приложение создает базу данных, эта база данных по умолчанию сохраняется в каталоге DATA/data/APP_NAME/databases/FILENAME.
Части указанного выше каталога построены на основе следующих правил. DATA - это путь, который возвращает метод Environment.getDataDirectory (). APP_NAME - это имя вашего приложения. FILENAME - это имя, которое вы указываете в коде приложения для базы данных.
Вы также можете проверить, есть ли в вашей среде IDE такая утилита, как перспектива DDMS Eclipse, которая позволяет вам просматривать каталог и / или копировать файлы в и из эмулятора или корневого устройства.
У меня странная проблема с Core Data в приложении iOS, где иногда файл WAL становится огромным (~ 1 ГБ). Похоже, что есть другие люди с проблемой (например, Core Data sqlite-wal файл получает MASSIVE ( > 7 ГБ) при вставке ~ 5000 строк).
Моя первоначальная мысль - удалить файл WAL при запуске приложения. Кажется, прочитав документацию sqlite по этому вопросу, это будет хорошо. Но кто-нибудь знает о каких-либо недостатках для этого?
Я, конечно же, хотел бы разобраться, почему файл WAL растет настолько большой, но сейчас я не могу разобраться с ним и хочу применить обходное решение, пока я копаю глубже в проблема.
Стоит отметить, что моя база данных Core Data больше кеша. Поэтому неважно, потеряю ли данные данные в WAL. Я действительно должен знать, будет ли база данных полностью повреждена, если я удалю WAL? Мое подозрение - нет, иначе WAL не выполняет одну из своих целей.
ОТВЕТЫ
Ответ 1
Режим WAL имеет проблемы, не используйте его. Проблемы различаются, но очень большой размер вашего отчета один, другие проблемы включают сбой во время миграции (с использованием NSPersistentStoreCoordinators migratePersistentStore) и сбой при импорте журналов транзакций iCloud. Таким образом, пока сообщается о преимуществах, пока эти ошибки не будут исправлены, вероятно, неразумно использовать режим WAL.
И нет, вы не можете удалить журнал записи Ahead, потому что он содержит самые последние данные.
Установите базу данных для использования режима журнала отката, и я думаю, вы обнаружите, что у вас больше нет этих очень больших файлов при загрузке большого количества данных.
Вот выдержка, в которой объясняется, как работает WAL. Если вы не можете гарантировать, что ваше приложение запустило контрольную точку, я не вижу, как вы можете удалить файл WAL, не рискуя удалить совершенные транзакции.
Как работает WAL
Традиционный журнал отката работает, написав копию исходный неизменный контент базы данных в отдельный журнал отката и затем записывать изменения непосредственно в файл базы данных. в событие сбоя или ROLLBACK, исходный контент, содержащийся в журнал отката воспроизводится в файле базы данных, чтобы вернуть файл базы данных в исходное состояние. COMMIT возникает, когда журнал отката удален.
Подход WAL инвертирует это. Исходный контент сохраняется в файл базы данных и изменения добавляются в отдельный WAL файл. COMMIT происходит, когда специальная запись с указанием фиксации прилагается к WAL. Таким образом, COMMIT может произойти без исходная база данных, которая позволяет читателям продолжать работать с оригинальная неизмененная база данных, в то время как изменения одновременно совершенных в WAL. Несколько транзакций могут быть добавлены к конец одного файла WAL.
Checkpointing
Конечно, каждый хочет в конечном итоге перенести все транзакции, которые добавляются в файл WAL обратно в исходную базу данных. перемещение транзакции WAL файла обратно в базу данных называются "Контрольные точки".
Еще один способ подумать о разнице между откатом и журнал записи-записи - это то, что в подходе с откатом-журналом есть две примитивные операции, чтение и письмо, тогда как с в журнале записи есть три примитивных операции: чтение, письменной форме и контрольной точке.
По умолчанию SQLite выполняет контрольную точку автоматически, когда файл WAL достигает порогового размера 1000 страниц. (The Параметр компиляции SQLITE_DEFAULT_WAL_AUTOCHECKPOINT может использоваться для укажите другое значение по умолчанию.) Приложения, использующие WAL, не должны выполнять все для того, чтобы эти контрольно-пропускные пункты произошли. Но если они хотят приложения могут регулировать порог автоматической контрольной точки. Или они могут отключать автоматические контрольные точки и выполнять контрольно-пропускные пункты во время холостых моментов или в отдельном потоке или процессе.
Ответ 2
Я бы не удалял файл журнала, но вы могли бы играть с возможностью вакуумирования SQLite файла, который заставит SQLite "уничтожить" файл журнала. Вы можете сделать это, добавив NSSQLiteManualVacuumOption как часть параметров при добавлении NSPersistentStore в NSPersistentStoreCoordinator .
Если это закончится тем, что потребуется много времени, я бы предложил отключить WAL. Я не видел никаких негативных последствий для его отключения (пока).
Ответ 3
Они дают разные решения:
Чтобы безопасно создавать резервные копии и восстанавливать хранилище SQLite Core Data, вы можете выполнить следующее:
Используйте следующий метод класса NSPersistentStoreCoordinator, а чем API-интерфейсы файловой системы, для резервного копирования и восстановления хранилища основных данных:
Обратите внимание, что это вариант, который мы рекомендуем.
Переход в режим ведения журнала отката при добавлении хранилища в постоянный координатор хранилища, если вам нужно скопировать файл хранилища. Листинг 1 - это код, показывающий, как это сделать:
Листинг 1 Используйте режим ведения журнала отката при добавлении постоянного хранилища
Для магазина, который был загружен в режиме WAL, если и основной файл хранилища, и соответствующий -wal файл существуют, используя режим ведения журнала отката, чтобы добавить хранилище в постоянный координатор магазина заставит Core Data выполнить контрольно-пропускной пункт который объединяет данные в файле -wal в файл хранилища. На самом деле это метод Core Data для выполнения операции контрольной точки. С другой стороны, если -wal файл отсутствует, используя этот подход к добавлению магазина не приведет к каким-либо исключениям, но транзакции, записанные в пропавшем -wal файле, будут потеряны.
ОЧЕНЬ ВАЖНОЕ ИЗМЕНЕНИЕ
Если некоторые из ваших пользователей находятся на iOS 8.1 , и вы выбрали первое решение (рекомендуемое Apple рекомендует), обратите внимание, что их отношения данных many-to-many будут полностью удалены. Потерял. Удаленные. Во всей перенесенной базе данных.
Ответ 4
Вы можете удалить файл WAL. Вы потеряете любые совершенные транзакции, которые не были отправлены обратно в основной файл. (Таким образом, нарушение "долговечности" части ACID, но, возможно, вам все равно.)
Мне не нравится все суеверное избиение режима WAL. Режим WAL более быстрый, более параллельный и намного более простой, поскольку он обойдется со всеми уровнями блокировки shenanigans (и большинство проблем с "базой данных занято" ), которые идут с журналами отката. Режим WAL - это правильный выбор практически во всех ситуациях. (Единственное место, где это проблематично, - это файловые системы флэш-памяти, которые не поддерживают доступ к файлам с распределенной памятью. В этом случае "неофициальная" директива компиляции SQLITE_SHM_DIRECTORY может использоваться для перемещения файла .shm в другую файловую систему - например, tmpfs - но это не должно быть проблемой для iOS.)
Ответ 5
Вы никогда не должны удалять SQL файл sqlite, он содержит транзакции, которые еще не были записаны в фактический файл sqlite. Вместо этого установите базу данных на контрольную точку, а затем очистите файл WAL для вас.
В CoreData лучший способ сделать это - открыть базу данных с помощью прагмы режима журнала DELETE. Это будет контрольная точка, а затем удалит файл WAL для вас.
Для здравого смысла вы должны убедиться, что у вас есть только одно соединение с постоянным хранилищем, когда вы это делаете, т.е. только один постоянный экземпляр хранилища в одном постоянном координаторе хранилища.
FWIW в вашем конкретном случае вы можете использовать TRUNCATE или OFF для первоначального импорта базы данных и переключиться на WAL для обновлений.
Обычно, когда на смартфоне заканчивается свободное место, люди начинают искать ненужные файлы, которые можно удалить, чтобы очистить память. Однако операционная система Android включает достаточно много директорий, которые ни в коем случае нельзя удалять.
Список файлов, которые нельзя удалять, и последствия их изъятия
Иногда список папок на разных версиях Андроид может отличаться, однако, в большинстве своем он одинаков. К важным данным ОС относятся папки:
- cache – отвечает за временные обновления, поэтому, если обновлять систему в планы не входит, ее можно удалить, но тогда ни одно обновление больше не сможет попасть на ваше устройство;
- data/app – хранит установочные данные приложений, ее можно убрать только в том случае, если вы не собираетесь работать с этими приложениями;
- data/clipboard – утилизировать эту папку категорически не рекомендуется, так как она отвечает за обмен данными;
- data/dalvik-cache – место, где хранится кеш-память, его нужно регулярно очищать, но ни в коем случае не удалять;
- documents – хранилище документов, которое можно очищать без вреда для работы смартфона, но не удалять;
- efs, etc, lib, mnt, proc, sbin, sys – эти названия нужно запомнить навсегда и обходить их стороной в процессе очистки памяти, так как в этих папках хранится важная информация для работоспособности смартфона, удаление которой может привести к серьезным проблемам;
- system – это костяк всей системы телефона, устранив его, придется заново прошивать гаджет.
Восстановить данные можно, но для этого нужно произвести сброс всех параметров до первоначальных настроек, поэтому это крайний метод, который приведет к удалению всего, что было в устройстве.
Итак, перед удалением любой папки в смартфоне, нужно узнать, стоит ли предпринимать такие действия. Неосторожное устранение файлов может привести не только к проблемам с работоспособностью телефона, но и к необходимости заново делать прошивку и установку исходных данных.
Я хотел бы удалить файл базы данных из Android file system программы? Можно ли запустить сценарий оболочки, adb который, в свою очередь, запускает сценарий оболочки в пространстве Android для удаления базы данных? Могу ли я сделать это из JUnit теста (с помощью system() звонка)?
Как удалить всю базу данных в Android? Мне нужно, чтобы все прошло, чтобы я мог проверить создание базы данных. Я могу отбросить таблицы, но этого недостаточно. Это в эмуляторе, а не на телефоне.
Когда у вас есть свой Контекст и вы знаете имя базы данных, используйте:
Когда эта строка запускается, база данных должна быть удалена.
Убедитесь, что вы закрыли все подключения базы данных перед удалением. В противном случае вам придется перезапустить приложение.
Это просто, просто наберите из вашей оболочки:
Для меня это не потребовало какой-либо специальной настройки. Я имею в виду, конечно, я автоматически вошел в систему как root, но все
Статический метод SQLiteDatabase.deleteDatabase (File file) был добавлен в API 16. Если вы хотите писать приложения, поддерживающие более старые устройства, как вы это делаете?
Я пытался: file.delete ();
но это портит SQLiteOpenHelper.
НЕВАЖНО! Позже я понял, что вы используете Context .deleteDatabase (). Context один прекрасно работает и удаляет журнал тоже. Работает для меня.
Кроме того, я обнаружил, что мне нужно вызвать SQLiteOpenHelp.close () перед выполнением удаления, чтобы затем я мог использовать LoaderManager для его воссоздания.
Также из Eclipse вы можете использовать DDMS, что делает его действительно простым.
Просто убедитесь, что ваш эмулятор работает, а затем переключитесь на перспективу DDMS в Eclipse. У вас будет полный доступ к File Explorer, который позволит вам войти и легко удалить всю базу данных.
Работает ли это с реальным устройством телефона? Я не мог видеть никаких подпапок в папке данных при просмотре в режиме DDMS.
Это может кому-то помочь. Вы должны упомянуть расширение, иначе оно не будет работать.
context.deleteDatabase (DATABASE_NAME); удалит базу данных, только если все соединения закрыты. Если вы поддерживаете одноэлементный экземпляр для обработки вашего помощника по базе данных - легко закрыть открытое соединение.
В случае, если база данных helper используется в нескольких местах путем непосредственного создания экземпляра, deleteDatabase + killProcess выполнит эту работу, даже если некоторые соединения открыты. Это можно использовать, если в сценарии приложения нет проблем при перезапуске приложения.
Удалить старую базу данных при удалении приложения.
Установка android: allowBackup = "false" в теге приложения в AndroidManifest.xml устранила проблему. Кажется, по какой-то странной причине ОС Android восстанавливала из резервной копии каждый раз, когда я развертывал приложение.
Вы можете создать файл объекта текущего пути к базе данных, а затем удалить его, как мы удаляем файл из папки
Я использовал метод удаления базы данных Android и база данных успешно удалена
Я использовал следующее для «форматирования» базы данных на устройстве после того, как изменил структуру базы данных в активах. Я просто раскомментирую строку в MainActivity, когда хочу, чтобы база данных снова читалась из ресурсов. Это сбросит значения и структуру базы данных устройства в соответствии с занятой базой данных в папке активов.
Далее я реализую кнопку, которая будет запускать deleteDatabase, чтобы пользователь мог сбросить свой прогресс в игре.
Из диспетчера приложений вы можете удалить все приложение с данными. Или просто данные сами по себе. Это включает в себя базу данных.
Перейдите в Настройки. Вы можете войти в меню настроек либо в меню приложений, либо, на большинстве телефонов, потянув вниз панель уведомлений и нажав там кнопку.
Выберите подменю Apps. На некоторых телефонах это меню будет иметь немного другое имя, например, Диспетчер приложений.
Проведите вправо до списка Все приложения. Игнорируйте списки запущенных и загруженных приложений. Вы хотите список всех приложений.
Выберите приложение, которое вы хотите отключить. Появится экран свойств с кнопкой для принудительной остановки в левом верхнем углу и другой кнопкой для отключения или удаления обновлений в правой верхней части.
У меня была та же проблема, проблема была в антивирусе, когда я деактивировал его, мое приложение работало хорошо, но когда я активировал его, я обнаружил некоторую ошибку "база данных заблокирована", я надеюсь, что это поможет вам.
В Linux и macOS вы можете сделать что-то подобное, например, если ваш заблокированный файл - development.db:
Эта команда покажет, какой процесс блокирует файл:
Просто убей процесс .
. И ваша база данных будет разблокирована.
. с очевидным предостережением, что вам нужно знать, что вы делаете. Если это неважный процесс, тогда все kill будет хорошо, но вы должны быть осторожны, чтобы убить его должным образом, и kill -9 , вероятно, это неправильно и / или излишне. Если процесс завис и не умрет иначе, иногда вам это нужно kill -9 . Но вы не хотите идти и убивать основное производственное задание, просто чтобы сообщить, что база данных больше не заблокирована!
@ chacham15: вы предполагаете, что база данных находится на «моем» компьютере, и вы игнорируете возможность запуска множества важных процессов на том же компьютере, что и тот, на котором заблокирована база данных. «Более простое» решение никогда не бывает таким простым;)
@KyleCarlson - sqlite и mysql принципиально отличаются в этом аспекте. Нет ничего особенно плохого в SQLite-db-browser.
Это решение предполагает, что существует процесс, блокирующий файл. Возможно, произошел сбой процесса, в результате чего файл SQLite оказался в непригодном для использования состоянии. В таком случае, смотрите мой ответ.
Я вызвал блокировку базы данных sqlite из-за сбоя приложения во время записи. Вот как я это исправил:
sqlite3: sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; /**** ERROR: (5) database is locked *****/ ROLLBACK; -- due to errors
Эта страница не объясняет, как SQLite решает, что что-то в вашем процессе имеет блокировку, и какие условия могут привести к ложному срабатыванию.
Удаление файла -journal звучит как ужасная идея. Он позволяет sqlite откатывать базу данных до согласованного состояния после сбоя. Если вы удалите его, когда база данных находится в несогласованном состоянии, то у вас останется поврежденная база данных. Ссылаясь на страницу с сайта sqlite :
Если происходит сбой или сбой питания, и на диске остается горячий журнал, важно, чтобы исходный файл базы данных и горячий журнал оставались на диске с их исходными именами, пока файл базы данных не будет открыт другим процессом SQLite и откатан , [. ]
Мы подозреваем, что обычный режим сбоя для восстановления SQLite происходит следующим образом: происходит сбой питания. После восстановления питания доброжелательный пользователь или системный администратор начинает осматривать диск на предмет повреждений. Они видят файл своей базы данных с именем "Important.data". Возможно, этот файл им знаком. Но после сбоя есть еще и горячий журнал под названием «важное.данные-журнал». Затем пользователь удаляет горячий журнал, думая, что он помогает очистить систему. Мы не знаем никакого способа предотвратить это, кроме обучения пользователей.
Предполагается, что откат произойдет автоматически при следующем открытии базы данных, но произойдет сбой, если процесс не сможет заблокировать базу данных. Как уже говорили другие, одна из возможных причин этого заключается в том, что в настоящее время этот процесс открыт. Другая возможность - устаревшая блокировка NFS, если база данных находится на томе NFS. В этом случае обходным путем является замена файла базы данных новой копией, которая не заблокирована на сервере NFS (mv database.db original.db; cp original.db database.db). Обратите внимание, что в FAQ по sqlite рекомендуется соблюдать осторожность при одновременном доступе к базам данных на томах NFS из-за ошибочных реализаций блокировки файлов NFS.
Я не могу объяснить, почему удаление файла -journal позволило бы вам заблокировать базу данных, которую вы не могли раньше. Это воспроизводимо?
Кстати, наличие файла -journal не обязательно означает, что произошел сбой или есть изменения, которые необходимо откатить. Sqlite имеет несколько разных режимов ведения журнала, а в режимах PERSIST или TRUNCATE он всегда оставляет файл -journal на своем месте и изменяет его содержимое, чтобы указать, существуют ли частичные транзакции для отката.
Если вы хотите удалить ошибку «база данных заблокирована», выполните следующие действия:
- Скопируйте файл базы данных в другое место.
- Замените базу данных на скопированную базу данных. Это разыменует все процессы, которые обращались к вашему файлу базы данных.
Если у процесса есть блокировка на базе данных SQLite и происходит сбой, она остается заблокированной навсегда. Это проблема. Дело не в том, что какой-то другой процесс имеет блокировку.
файлы базы данных SQLite - это просто файлы, поэтому первым шагом было бы убедиться, что они не только для чтения. Другая вещь, которую нужно сделать, - убедиться, что у вас нет какой-либо программы просмотра БД SQLite с графическим интерфейсом при открытой БД. Вы можете открыть базу данных в другой оболочке, или ваш код может открыть базу данных. Обычно это можно увидеть, если в другом потоке или приложении, таком как SQLite Database Browser, БД открыта для записи.
По моему опыту, SQLite Database Browser (SDB) воспроизводимо блокирует базу данных, если вы редактируете данные, но не сохраняете ее в SDB. Если вы сохраните его, он снимет блокировку.
У меня была эта проблема только сейчас, с использованием базы данных SQLite на удаленном сервере, хранящейся в монтировании NFS. SQLite не удалось получить блокировку после того, как сеанс удаленной оболочки, который я использовал, потерпел крах, когда база данных была открыта.
Предложенные выше рецепты восстановления не сработали (включая идею сначала переместить, а затем скопировать базу данных обратно). Но после копирования в систему, отличную от NFS, база данных стала пригодной для использования, и данные, похоже, не были потеряны.
Моя блокировка была вызвана сбоем системы, а не зависанием. Чтобы решить эту проблему, я просто переименовал файл, а затем скопировал его обратно в исходное имя и местоположение.
Использование оболочки Linux, которая была бы .
Я добавил " Pooling=true " в строку подключения, и это сработало.
Я нашел документацию о различных состояниях блокировки в SQLite очень полезной. Майкл, если вы можете выполнять чтение, но не можете выполнять запись в базу данных, это означает, что процесс получил зарезервированную блокировку в вашей базе данных, но еще не выполнил запись. Если вы используете SQLite3, есть новая блокировка, называемая PENDING, в которой больше не разрешено подключать больше процессов, но существующие соединения могут выполнять чтение, поэтому, если это проблема, вы должны рассмотреть ее.
Эта ошибка может быть выдана, если файл находится в удаленной папке, например в общей папке. Я изменил базу данных на локальный каталог, и он работал отлично.
У меня есть такая проблема в приложении, что доступ к SQLite из 2-х подключений - одно только для чтения, а второе для записи и чтения. Похоже, что соединение только для чтения заблокировало запись со второго соединения. Наконец, оказывается, что необходимо завершить или, по крайней мере, сбросить подготовленные операторы НЕМЕДЛЕННО после использования. До тех пор, пока готовый оператор не будет открыт, он вызвал, что база данных была заблокирована для записи.
НЕ ЗАБЫВАЙТЕ ЗВОНИТЬ:
Некоторые функции, такие как INDEX'ing, могут занимать очень много времени и блокировать всю базу данных во время работы. В таких случаях он может даже не использовать файл журнала!
Поэтому лучший / единственный способ проверить, заблокирована ли ваша база данных, потому что процесс АКТИВНО записывает в нее (и, таким образом, вы должны оставить его в покое, пока он не завершит свою работу), - это md5 (или md5sum в некоторых системах) файл дважды , Если вы получаете другую контрольную сумму, база данных пишется, и вы действительно ДЕЙСТВИТЕЛЬНО не хотите уничтожать этот процесс, потому что вы можете легко получить поврежденную таблицу / базу данных, если вы это сделаете.
Я еще раз повторю, потому что это важно - решение НЕ в том, чтобы найти программу блокировки и убить ее, а в том, чтобы найти, есть ли в базе данных блокировка записи по уважительной причине, и пойти дальше. Иногда правильное решение - просто перерыв на кофе.
Единственный способ создать эту заблокированную, но не записываемую ситуацию - это если ваша программа выполняется BEGIN EXCLUSIVE , потому что она хотела внести какие-то изменения в таблицу или что-то еще, то по какой-либо причине никогда не отправляет END потом, и процесс никогда не завершается . Все три выполняемых условия крайне маловероятны в любом правильно написанном коде, и, таким образом, в 99 случаях из 100, когда кто-то хочет уничтожить -9 свой процесс блокировки, процесс блокировки фактически блокирует вашу базу данных по уважительной причине. Программисты обычно не добавляют BEGIN EXCLUSIVE условие, если в этом нет особой необходимости, поскольку оно предотвращает параллелизм и увеличивает количество жалоб пользователей. Сам SQLite добавляет его только тогда, когда это действительно необходимо (например, при индексации).
Наконец, статус «заблокирован» не существует ВНУТРИ файла, как указано в нескольких ответах, - он находится в ядре операционной системы. Запущенный процесс BEGIN EXCLUSIVE запросил у ОС блокировку файла. Даже если ваш эксклюзивный процесс потерпел крах, ваша ОС сможет выяснить, должна ли она поддерживать блокировку файла или нет !! Невозможно получить базу данных, которая заблокирована, но ни один процесс не блокирует ее активно !! Когда дело доходит до выяснения, какой процесс блокирует файл, обычно лучше использовать lsof, а не fuser (это хорошая демонстрация того, почему: /unix/94316/fuser-vs-lsof- проверять используемые файлы ). Кроме того, если у вас есть DTrace (OSX), вы можете использовать iosnoop для файла.
Где находятся системные файлы в Андроид и почему их лучше не трогать
Проводя анализ данных гаджета, можно заметить, что встроенные утилиты системы занимают много места. Многие файлы удалить невозможно, так как в настройках нет такой функции, однако, если пользователь получит доступ и избавиться от них, это может привести к серьезным последствиям.
Многих пользователей смартфонов интересует, можно ли удалить все данные, которые изначально были встроены в памяти устройства? Специалисты, отвечая на этот вопрос, утверждают, что некоторые утилиты удалять можно, но большинство все-таки трогать нельзя, так как при устранении важного софта можно столкнуться с потерей некоторых функций телефона, вплоть до того, что он перестанет работать или начнет постоянно перезагружаться.
Стоит отметить, что самые важные системные файлы находятся в папках data и system. Удалить их оттуда самостоятельно нельзя, так как для этого нужно иметь Root-права, а именно полномочия администратора гаджета. Если получить этот доступ, то юзер сможет устранять из памяти смартфона все, что захочет, но без данного права получится лишь отключить ту или иную программу в настройках.
Встроенный данные на телефоне делятся на три вида:
- системное программное обеспечение, которое отвечает за продуктивную работу устройства, удаление таких данных определенно будет иметь последствия;
- сервисы Google, которые можно легко отключить в настройках в случае ненадобности, но стоит понимать, что если убрать, например, карты, то приложения, в которых необходимо разрешение навигации, станут недоступными;
- приложения от производителя, которые в большинстве своем можно убрать, но делать это нужно также аккуратно.
Следовательно, прежде чем удалять тот или иной файл, нужно узнать, к какой категории программ он относится, и можно ли производить очистку.
Читайте также: