Журнал базы данных, чем открыть

Обновлено: 03.07.2024

Недавно со мной связался клиент полиции, который обнаружил компрометирующее имя файла в журнале отката SQLite и попросил помощи в переводе данных в удобный для пользователя формат. По имеющимся данным, подозреваемый использовал мессенджер Kik на устройстве Android и удалил несколько сообщений. Сам файл в формате jpeg был найден, но им нужно было связать его с сообщением и поместить в контекст с другими сообщениями вокруг него.

Процесс, который я предложил использовать Forensic Toolkit для SQLite, довольно прост и подробно описан в конце этой статьи. Но я решил написать некоторые из своих наблюдений о том, стоит ли вручную «откатывать» журнал самостоятельно, и почему я решил этого не делать.

SQLite поддерживает два типа журналов: старый файл журнала отката, который я буду обсуждать в большей части этой статьи, и новый файл журнала записи с опережением (WAL), который я здесь не буду рассматривать (однако тот же метод, предлагаемый в конец этой статьи можно использовать для работы с файлами WAL). Одновременно можно использовать только один тип журнала. Журналы ведутся таким образом, что в случае возникновения ошибки при обновлении базы данных SQLite может вернуться к последней хорошей позиции, т. е. до выполнения транзакции записи.

При обновлении, создании или удалении записи в базе данных, использующей журнал отката, вся страница базы данных, содержащая эту запись, сначала копируется в файл журнала отката. Затем база данных обновляется. Если SQLite дает сбой при перезапуске, он проверяет журнал на наличие действительных записей (подробнее о «действительных» позже), если они присутствуют, он «откатывает» журнал, т. е. копирует страницы из журнала обратно в базу данных.

Обновления базы данных обычно происходят как часть транзакции, и обычно сразу обновляется множество записей, например, если несколько записей обновляются или удаляются. Когда все транзакции завершены, изменения «фиксируются» в базе данных. Записи для разных таблиц хранятся в базе данных на страницах, поэтому, если несколько страниц обновляются как часть транзакции, в журнале будет существовать несколько страниц.

Действительный журнал начинается с раздела заголовка, который увеличен до размера 1 сектора (обычно 512 байт). Размер сектора записывается в заголовке. Фактически используются только первые 28 байтов заголовка. В заголовке также указывается количество страниц в текущем журнале, случайное начальное число (известное как одноразовый номер), используемое для вычисления контрольной суммы для каждой страницы, и размер страницы базы данных.

За этим следуют сохраненные страницы из базы данных, причем каждая страница хранится последовательно следующим образом:


Есть несколько моментов, на которые следует обратить внимание в описании по ссылке формата файла выше:

  • Журнал действителен только в том случае, если он содержит допустимый заголовок.
  • Одна и та же страница не должна встречаться в журнале более одного раза.
  • Контрольная сумма для каждой страницы вычисляется по определенным байтам с одноразовым номером из заголовка журнала.
  • Для каждой транзакции используется новый одноразовый номер
  • Когда транзакция зафиксирована, журнал помечается как недействительный путем его удаления, усечения до 0 байт или очистки сектора заголовка журнала.

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

Однако есть одна сложность. Если большой объем данных, скажем, 1000 страниц, записывается в журнал, а затем фиксируется, эти 1000 страниц остаются после фиксации транзакции, и стирается только заголовок журнала. Если следующая транзакция содержит только 3 страницы, то эти 3 страницы перезаписывают первые 3 страницы предыдущей транзакции. Следующая транзакция может состоять из 30 страниц и т. д. Конечно, это может произойти и происходит несколько раз с разным количеством страниц.

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

В присланном мне журнале первые 21 страница были следующими:


Если бы заголовок был неповрежденным, мы могли бы использовать одноразовый номер (иногда называемый SALT) из заголовка и данные из сохраненной страницы для проверки контрольной суммы каждой страницы по очереди.Получив несовпадающую контрольную сумму, мы знаем, что все страницы до первого несоответствия и все последующие страницы (включая первое несоответствие) взяты из одного или нескольких предыдущих журналов

Мы видим, что страница БД 1 находится на страницах журнала 3 и 4, а страница БД 90 — на страницах 14 и 21. Возвращаясь к нашим пунктам выше, мы видим, что страница может существовать только один раз в действительном журнале, поэтому отсюда можно сделать вывод, что в этом журнале присутствуют страницы как минимум из трех транзакций.

Поскольку первая страница базы данных всегда обновляется, когда база данных использует режим журнала (не режим WAL), мы можем сделать предположение, что последней записью были страницы 86, 4 и 1, поскольку в спецификации указано, что страница из база данных может встречаться только один раз в любом допустимом журнале, поэтому страница базы данных 1 на странице журнала 4 ДОЛЖНА быть из предыдущей резервной копии. Точно так же мы можем также сказать, что журнал снова изменяется где-то между страницей журнала 15 и страницей журнала 21 (поскольку страница базы данных 90 не может появляться дважды в одном и том же журнале).

Возвращаясь к проблеме просмотра данных, какие у нас есть варианты?

В любом случае мы могли бы откатить весь журнал (нам нужно было бы написать программу, которая записывала бы каждую страницу журнала обратно в правильное место в базе данных. Я решил, что это чревато потенциальными проблемами. Страница 1 — это просто заголовок БД, и он обновляется при каждой фиксации базы данных, но страница БД 90 также присутствует в журнале в двух местах, поэтому какой из них мы используем.

Мне не нравится эта идея!

Мы могли бы вставить каждую запись на каждой странице журналов в файл KikDatabase.db (основную базу данных SQLite для Kik). В этом тоже есть свои проблемы:

Мы знаем, что в журнале несколько транзакций, поэтому может быть несколько копий одной и той же записи. Идентификатор для каждой строки в messagesTable представляет собой целочисленный первичный ключ (см. далее), и ограничения таблицы для первичного ключа (должны быть уникальными) будут нарушены, если мы попытаемся вставить более одной записи с одним и тем же идентификатором. С более сложными схемами баз данных этот вопрос становится еще более актуальным. Или как насчет вставки внутренней конечной страницы, которая нарушила отношения родитель-потомок в двоичном дереве, в котором хранится каждая таблица?
Даже если бы это было успешно, данные из журнала теперь будут перемежаться с данными, которые в настоящее время существуют в действующей базе данных, и не будет возможности различить два набора записей.

Мне не нравится эта идея!

Мы могли бы попытаться определить, где заканчивается последний действительный журнал, и откатить только те записи, которые были до этого места. Но этот момент не всегда очевиден, и он по-прежнему не позволяет получить страницы, кроме последней «хорошей» страницы, которую мы выбираем.

Значит, мне эта идея тоже не нравится!

Выбранное мной решение также оказалось самым простым и не требовало нового кода. Используйте Forensic Recovery для SQLite, чтобы вырезать данные непосредственно из журнала и создать новую базу данных только с записями из журнала. Все, что нам нужно сделать, это убедиться, что шаблон создан для KikDatabase, это можно сделать, просто указав Forensic Recovery for SQLite на существующую базу данных, следуя инструкциям мастера (эти шаги очень просты и подробно описаны позже). Forensic Recovery for SQLite отобразит таблицы в соответствии с исходной схемой (с снятыми ограничениями, поэтому разрешены повторяющиеся записи), показывая все записи, а также создаст новую базу данных SQLite, которую мы можем изучить с помощью Forensic Browser for SQLite.

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

Чтобы понять, как мы можем это сделать, давайте немного отвлечемся и посмотрим на SQL для messagesTable – следующим образом:

Код:

CREATE TABLE messagesTable (_id INTEGER PRIMARY KEY AUTOINCREMENT, body VARCHAR, partner_jid VARCHAR, was_me INT, read_state INT, uid VARCHAR, длина INTEGER, временная метка LONG, bin_id VARCHAR, sys_msg VARCHAR, stat_msg VARCHAR, stat_user_jid VARCHAR, reqread _read VARCHAR, app_id VARCHAR, message_retry_count INT, encoding_failure BOOLEAN по умолчанию 0, Encryption_key BLOB, render_instructions VARCHAR)

Особое значение имеет первый столбец «_id INTEGER PRIMARY KEY AUTOINCREMENT»
В этом столбце указано, что _id является первичным ключом — это означает, что это поле должно быть уникальным.В нем также говорится, что это поле «автоинкрементируется», это означает, что даже если строка удалена, следующая вставленная строка не будет повторно использовать удаленный _id, а будет автоматически увеличиваться с последнего (наибольшего) использованного значения. < /p>

Кстати, следующее значение для автоматического увеличения хранится в таблице sqlite_sequence. В нашей базе данных эта таблица, как показано ниже, сообщает нам, что последний _id, использованный для messagesTable, был 7603, т. е. следующим будет использоваться 7604.


Поэтому в Forensic Browser для SQLite мы создаем запрос, который фильтрует восстановленные данные на основе поля _id и ограничивает возвращаемые данные теми строками, которые не существуют в оригинале. Сначала откройте действующую базу данных — эта база данных будет иметь полный префикс «main». Теперь прикрепите восстановленную базу данных и прикрепите ее как «восстановленную», вставьте приведенный ниже запрос в редактор запросов SQL и выполните запрос:

Код:

ВЫБЕРИТЕ *ИЗ восстановленной.messagesTable
ГДЕ восстановленная.messagesTable._ID НЕ В
(ВЫБЕРИТЕ main.messagesTable._id ИЗ main.messagesTable)

На английском языке это делает следующее, строка за строкой:

a) Выбирает все сообщения из восстановленной таблицы,
b) но, только если идентификатор записи в a) отсутствует в:
c) списке полного набора _id поля, возвращаемые из активной (основной) базы данных.

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


Как упоминалось выше, процесс настройки шаблона и вырезания из файла журнала на самом деле довольно прост:

  • Запустите Forensic Recovery для SQLite и воспользуйтесь мастером
  • Когда вы перейдете на страницу шаблонов, щелкните правой кнопкой мыши "таблицу приложений" и выберите "импортировать таблицы из баз данных SQLite".


  • Перейдите к файлу KikDatabase.db и выберите его.
  • Назовите свой шаблон, например, "Kik – Android".


  • Убедитесь, что только новый шаблон, который вы создаете (Kik – Android в моем примере), отмечен флажком (вы не хотите, чтобы вкладки создавались для всех других приложений)
  • Снимите флажок "Поиск определений базы данных" — в этом нет необходимости, так как мы вырезаем данные из известного журнала.


  • Наконец выберите файл KikDatabase.db-journal на вкладке файлов.

Мастер теперь должен завершиться и показать вам все записи в журнале. Вырезанная таблица сообщений выглядит в SQLite Recovery следующим образом:


Чтобы увидеть, где именно была найдена конкретная запись, вы можете дважды щелкнуть строку (на рисунке выше), и SQLite Forensic Recovery отобразит исходный файл, базу данных и смещение вырезанной записи, как показано ниже:


Теперь вы также можете открыть созданную базу данных из папки, выбранной на первой странице мастера, с помощью The Forensic Browser for SQLite и создать пользовательские отчеты и/или выполнить описанный выше SQL-запрос, чтобы выбрать только удаленные записи.< /p>

DB-JOURNAL — это формат файла журнала, используемый ядром базы данных SQLite. Файл DB-JOURNAL создается SQLite для каждой транзакции базы данных в качестве временного хранилища данных.

DB-JOURNAL позволяет базе данных откатывать свое состояние до предыдущего в случае сбоя приложения при выполнении транзакции или внезапного сбоя питания. Таким образом, файлы DB-JOURNAL служат средством сохранения целостности базы данных.

Программы, которые могут открыть файл .DB-JOURNAL

Окна
Mac OS
Линукс

Как открыть файлы DB-JOURNAL

Если появилась ситуация, в которой Вы не можете открыть файл DB-JOURNAL на своем компьютере - причин может быть несколько. Первой и одновременно самой важной (встречается чаще всего) является отсутствие соответствующей аппликации обслуживающей DB-JOURNAL среди установленных на Вашем компьютере.

Очень простой способ решить эту проблему — найти и загрузить соответствующее приложение. Первая часть задачи уже выполнена — программное обеспечение, поддерживающее файл DB-JOURNAL, можно найти в таблице. Теперь просто скачайте и установите соответствующее приложение.

Возможные проблемы с файлами формата DB-JOURNAL

Невозможность открытия файла DB-JOURNAL и работы с ним не обязательно означает, что на вашем компьютере не установлено соответствующее программное обеспечение. Могут быть и другие проблемы, которые также блокируют нашу способность работать с файлом журнала базы данных SQLite. Ниже приведен список возможных проблем.

  • Повреждение открываемого файла DB-JOURNAL
  • Неверные ссылки на файл DB-JOURNAL в записях реестра.
  • Случайное удаление описания файла DB-JOURNAL из реестра Windows
  • Неполная установка приложения, поддерживающего формат DB-JOURNAL
  • Открываемый файл DB-JOURNAL инфицирован нежелательным, вредным программным обеспечением.
  • На компьютере недостаточно аппаратных ресурсов, чтобы открыть файл DB-JOURNAL.
  • Драйверы оборудования, используемого компьютером для открытия файла DB-JOURNAL, устарели.

Если вы уверены, что все эти причины отсутствуют в вашем случае (или уже устранены), файл DB-JOURNAL должен без проблем работать с вашими программами. Если проблема с файлом DB-JOURNAL все-таки не решена, это может значить, что в этом случае появилась другая, редкая проблема с файлом DB-JOURNAL. В этом случае единственное, что вы можете сделать, это обратиться за помощью к профессиональным сотрудникам.

Суффикс имени файла DB-JOURNAL в основном используется для файлов журнала базы данных SQLite. Спецификация журнала базы данных SQLite была создана командой разработчиков SQLite. Файлы DB-JOURNAL поддерживаются программными приложениями, доступными для устройств под управлением Linux, Mac OS, Windows. Формат файла DB-JOURNAL, наряду с 403 другими форматами файлов, относится к категории файлов базы данных. Пользователям рекомендуется использовать программное обеспечение SQLite для управления файлами DB-JOURNAL, хотя 4 другие программы также могут обрабатывать файлы этого типа. Программное обеспечение SQLite было разработано командой разработчиков SQLite, и на ее официальном веб-сайте вы можете найти дополнительную информацию о файлах DB-JOURNAL или программном обеспечении SQLite.

Программы, поддерживающие расширение файла DB-JOURNAL

Следующий список содержит программы, сгруппированные по 3 операционным системам, которые поддерживают файлы DB-JOURNAL. Файлы с расширением DB-JOURNAL, как и файлы любых других форматов, можно найти в любой операционной системе. Рассматриваемые файлы могут быть переданы на другие устройства, будь то мобильные или стационарные, но не все системы могут правильно обрабатывать такие файлы.

Программы, поддерживающие файл DB-JOURNAL

Windows

Окна

MAC OS

ОС MAC

Linux

Линукс

Как открыть файл с расширением DB-JOURNAL?

Невозможность открывать файлы с расширением DB-JOURNAL может иметь различное происхождение. Что важно, все распространенные проблемы, связанные с файлами с расширением DB-JOURNAL, могут решать сами пользователи. Процесс быстрый и не требует участия ИТ-специалиста. Мы подготовили список, который поможет вам решить ваши проблемы с файлами DB-JOURNAL.

Шаг 1. Установите программное обеспечение SQLite

Установите программу, чтобы открыть файл DB-JOURNAL

Основная и наиболее частая причина, препятствующая открытию пользователями файлов DB-JOURNAL, заключается в том, что в системе пользователя не установлена ​​программа, которая может обрабатывать файлы DB-JOURNAL. Это легко. Выберите SQLite или одну из рекомендуемых программ (например, TextEdit, Блокнот Windows, текстовый редактор NotePad++), загрузите ее из соответствующего источника и установите в своей системе. Выше вы найдете полный список программ, поддерживающих файлы DB-JOURNAL, классифицированных в соответствии с системными платформами, для которых они доступны. Если вы хотите загрузить установщик SQLite наиболее безопасным способом, мы рекомендуем вам посетить веб-сайт команды разработчиков SQLite и загрузить его из официальных репозиториев.

Шаг 2. Убедитесь, что у вас установлена ​​последняя версия SQLite

Обновление программного обеспечения, поддерживающего расширение файла DB-JOURNAL

Если проблемы с открытием файлов DB-JOURNAL по-прежнему возникают даже после установки SQLite, возможно, у вас устаревшая версия программного обеспечения. Проверьте веб-сайт разработчика, доступна ли более новая версия SQLite. Также может случиться так, что создатели программного обеспечения, обновляя свои приложения, добавляют совместимость с другими, более новыми форматами файлов. Это может быть одной из причин, по которой файлы DB-JOURNAL несовместимы с SQLite.Все форматы файлов, которые прекрасно обрабатывались предыдущими версиями данной программы, также должны открываться с помощью SQLite.

Шаг 3. Свяжите файлы журнала базы данных SQLite с SQLite

Если проблема не была решена на предыдущем шаге, вам следует связать файлы DB-JOURNAL с последней версией SQLite, установленной на вашем устройстве. Процесс связывания форматов файлов с приложением по умолчанию может различаться в деталях в зависимости от платформы, но основная процедура очень похожа.

Связать программное обеспечение с файлом DB-JOURNAL в Windows

Процедура изменения программы по умолчанию в Windows

  • Выберите пункт «Открыть с помощью» в меню «Файл», к которому можно щелкнуть правой кнопкой мыши файл DB-JOURNAL.
  • Нажмите «Выбрать другое приложение», а затем выберите «Другие приложения».
  • Чтобы завершить процесс, выберите «Искать другое приложение на этом компьютере» и с помощью проводника выберите папку установки SQLite. Подтвердите, установив флажок Всегда использовать это приложение для открытия файлов DB-JOURNAL и нажав кнопку OK.

Процедура изменения программы по умолчанию в Mac OS

  • Нажав правую кнопку мыши на выбранном файле DB-JOURNAL, откройте меню файла и выберите Информация.
  • Откройте раздел "Открыть с помощью", нажав на его название.
  • Выберите SQLite и нажмите Изменить для всех.
  • Если вы выполнили предыдущие шаги, должно появиться сообщение: Это изменение будет применено ко всем файлам с расширением DB-JOURNAL. Затем нажмите кнопку "Продолжить", чтобы завершить процесс.

Шаг 4. Проверьте DB-JOURNAL на наличие ошибок

Если вы следовали инструкциям из предыдущих шагов, но проблема все еще не решена, вам следует проверить соответствующий файл DB-JOURNAL. Возможно, файл поврежден и поэтому недоступен.

Проверить файл DB-JOURNAL на наличие вирусов

1. Проверьте файл DB-JOURNAL на наличие вирусов или вредоносных программ

Если файл заражен, вредоносное ПО, находящееся в файле DB-JOURNAL, препятствует попыткам открыть его. Немедленно просканируйте файл с помощью антивирусного инструмента или просканируйте всю систему, чтобы убедиться, что вся система безопасна. Если файл DB-JOURNAL действительно заражен, следуйте приведенным ниже инструкциям.

2. Проверьте, не поврежден ли файл

Вы получили рассматриваемый файл DB-JOURNAL от другого лица? Попросите его/ее отправить его еще раз. В процессе копирования файла могут возникнуть ошибки, из-за которых файл будет неполным или поврежденным. Это может быть источником возникших проблем с файлом. Если файл DB-JOURNAL был загружен из Интернета только частично, попробуйте загрузить его повторно.

3. Проверьте, есть ли у пользователя, под которым вы вошли в систему, права администратора.

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

4. Проверьте, поддерживает ли ваша система SQLite

Операционные системы могут иметь достаточно свободных ресурсов для запуска приложения, поддерживающего файлы DB-JOURNAL. Закройте все запущенные программы и попробуйте открыть файл DB-JOURNAL.

5. Убедитесь, что у вас установлены последние версии драйверов, системных обновлений и исправлений

Обновленная система и драйверы не только делают ваш компьютер более безопасным, но также могут решить проблемы с файлом журнала базы данных SQLite. Устаревшие драйверы или программное обеспечение могли привести к невозможности использования периферийного устройства, необходимого для обработки файлов DB-JOURNAL.

Вы хотите помочь?

Если у вас есть дополнительная информация о файле DB-JOURNAL, мы будем признательны, если вы поделитесь ею с нашими пользователями. Для этого воспользуйтесь формой здесь и отправьте нам информацию о файле DB-JOURNAL.

У меня должна быть возможность удалить файл базы данных, когда я ничего не делаю с базой данных.

Приложение должно очищать файлы блокировки, когда я его закрываю.

Что вы увидели вместо этого?

Файлы журнала/блокировки все еще там. Этого НЕ происходит, если я открываю его в обычном режиме (без опции «Только для чтения»).

image

Полезная дополнительная информация

Приведенная ниже информация часто бывает полезной. Пожалуйста, заполните ее, если можете. :)

Какую операционную систему вы используете?

  • Windows: ( _version: 10 )
  • Linux: ( дистрибутив: ___ )
  • Mac OS: ( версия: ___ )
  • Другое: ___

Какая у вас версия DB4S?

  • 3.11.2
  • 3.11.1
  • 3.10.1
  • Другое: ___

Вы также

П.s: сегодняшняя ночная сборка кажется испорченной, лол, но я все же смог протестировать функцию только для чтения, файлы не очищаются.

Текст был успешно обновлен, но возникли следующие ошибки:

datvm прокомментировал 29 декабря 2019 г.

Есть ли способ отключить соединение, если я ничего не делаю? То есть, после того, как браузер БД завершит оператор SELECT, просто разорвать соединение с БД и снова подключить его, как только я взаимодействую с приложением? Я знаю, что это снизит производительность, но меня это устраивает, если я могу не блокировать свой файл. Я знаю, что это немного специфично для моего случая, поэтому я совершенно не против, если это невозможно :)

комментарий justinclift прокомментировал 29 декабря 2019 г.

Я лично не знаю, как это сделать, но кто-то другой может знать.

При этом, если вам просто нужен вывод команды SQL и не нужен открытый графический интерфейс, то, возможно, лучшим подходом будет прямой вызов интерфейса командной строки SQLite ( sqlite.exe )?

datvm прокомментировал 29 декабря 2019 г. •

Извините, позвольте мне немного пояснить, мне нужен пользовательский интерфейс, чтобы увидеть, что представляют собой значения, просто в этом случае мне не нужно часто взаимодействовать после этого. Мой рабочий процесс в настоящее время:

Запустить скрипт → Открыть браузер БД → Открыть файл базы данных → Проверить значения → Изменить скрипт → Закрыть браузер БД → Запустить скрипт → повторить

Просто немного неудобно, когда я забываю закрыть браузер БД, а файл заблокирован, или при повторном открытии браузера БД мне приходится проходить через пользовательский интерфейс, чтобы снова выбрать таблицу. Вот почему я прошу, чтобы DB Browser создавал соединение, выполнял все необходимые запросы, а затем закрывал его и ничего не делал, пока я снова не нажму «Обновить» (что-то вроде Notepad++).

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

прокомментировал mgrojo 29 декабря 2019 г.

Файл журнала не создается, когда БД открыта в режиме только для чтения (по крайней мере, я могу наблюдать это на своей платформе). Он также не удаляется при закрытии БД, потому что он не был создан в этом соединении. Вы должны открыть его для чтения-записи, сохранить некоторые изменения, а затем он автоматически удаляется.

Относительно удаления файла, когда он открыт приложением, это стандартное поведение Windows. Файл заблокирован от удаления.

Вам не подойдет следующая процедура? Закройте БД (Ctrl+F4 в nightly, Ctrl+W в предыдущих версиях), поработайте с файлом извне, а затем снова откройте его (Ctrl+1, при условии, что в промежутке между ними не открывались файлы БД).

datvm прокомментировал 30 декабря 2019 г.

Я также прилагаю файл базы данных, если это из-за файла:

Относительно удаления файла, когда он открыт приложением, это стандартное поведение Windows. Файл заблокирован от удаления.

Это правильно, и я не возражаю против этого. Однако я предложил, если это возможно, браузер БД не держит его открытым (я использовал слово «серьезное соединение» в предыдущем посте). Это поведение похоже на Notepad++, когда вы открываете файл, вы по-прежнему можете удалить или изменить его в другом месте, потому что после завершения чтения файла Notepad++ не удерживает его.

прокомментировал mgrojo 30 декабря 2019 г.

Спасибо за видео и вложение. Теперь понятно, почему я его не воспроизвел. У меня была база данных в режиме журнала по умолчанию (DELETE). В этом случае до изменения базы данных нет файла журнала.

В вашем случае он установлен в режим WAL, который согласно документации:

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

С каждой базой данных связан дополнительный квазипостоянный файл "-wal" и файл общей памяти "-shm", что может сделать SQLite менее привлекательным для использования в качестве формата файла приложения.

Таким образом, даже в режиме только для чтения SQLite создает и сохраняет эти файлы wal и shm, и кажется, что мы ничего не можем с этим поделать. У вас есть возможность переключить режим журнала на DELETE, если вы не зависите от режима WAL, и открытие базы данных в режиме только для чтения никогда не создаст файл журнала, и в любом случае этот файл не будет сохраняться при подключении к базе данных. закрыто.

Относительно удаления файла, когда он открыт приложением, это стандартное поведение Windows. Файл заблокирован от удаления.

Это правильно, и я не возражаю против этого. Однако я предложил, если это возможно, браузер БД не держит его открытым (я использовал слово «серьезное соединение» в предыдущем посте).Это поведение похоже на Notepad++, когда вы открываете файл, вы по-прежнему можете удалить или изменить его в другом месте, потому что после завершения чтения файла Notepad++ не удерживает его.

Это не то же самое, что открыть файл в редакторе, где весь файл считывается в буфер памяти и сохраняется и обновляется там до тех пор, пока файл не будет сохранен, когда он будет полностью заменен на диске; чем открытие соединения с файлом БД, где файл не будет полностью прочитан в памяти и никогда не будет полностью заменен. DB Browser может закрыть соединение и снова открыть его перед выполнением любого запроса, но это будет медленно и громоздко. Я не могу говорить за других разработчиков, но я не вижу, чтобы это происходило.

Читайте также: