Обновили программу на ПК, откатили версию — база больше не открывается

Три версии, которые надо различать

• Версия установленной программы: какой код запускает сотрудник.
• Версия формата данных приложения: какие таблицы и смысл полей ожидаются.
• Версия движка хранения: например, конкретная SQLite, включённая в поставку.

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

Сначала определите договор совместимости

Для каждого выпуска зафиксируйте, какие версии данных разрешено читать и изменять. Чтение и запись могут иметь разные границы. Временный режим «только просмотр» иногда полезнее полного отказа, но только если чтение действительно корректно: неизвестные статусы, единицы и связи способны искажать отчёт без явной ошибки.

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

Что сохранить перед миграцией

Получите согласованную резервную копию данных и необходимых вложений. Запишите исходную версию, проверяемый результат и способ восстановления. Обычное копирование одного активного файла базы не всегда даёт согласованный снимок; используйте поддерживаемый механизм программы или базы.

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

Обратная миграция — самостоятельная работа

Если новое поле можно удалить без потери смысла, возврат кажется простым. Но объединение двух сущностей, изменение единиц или потеря старой детализации могут быть необратимыми. Сценарий назад нужно проектировать отдельно, а иногда вместо него разумнее восстановить предмиграционную копию и согласованно перенести последующие операции.

Такое восстановление тоже имеет последствия: данные, появившиеся после копии, не должны исчезнуть незаметно. До отката определите остановку работы, выгрузку новых событий и ответственного за сверку. Нельзя обещать пользователю «всё останется», пока механизм не испытан на похожих данных.

Проверка выпуска на копии реальной структуры

1. Запустить обновление на обезличенной копии поддерживаемой старой версии.
2. Проверить важные записи, суммы, вложения и поиск после преобразования.
3. Имитировать прерывание на предусмотренном этапе и повторный запуск.
4. Попробовать старую программу: она должна корректно отказать или работать только в заявленном режиме.
5. Выполнить запланированное восстановление и сверить новые операции.

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

Матрица допустимых запусков

В инструменте задаётся версия прикладного формата, а в строках — диапазоны чтения и записи каждого выпуска. Прочерк в диапазонах записи означает отсутствие режима записи. Результат помогает проверить договор совместимости, но не анализирует исходный код и не доказывает, что приложение действительно соблюдает объявленные границы.

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