SQLite: SQLite сообщает no such column после изменения схемы

#Что происходит и когда инструкция применима

Сообщение no such column после изменения схемы возникает, когда SQL обращается к переименованному полю или приложение использует не ту версию схемы. Нужно сопоставить фактический SQL, структуру БД и применённую миграцию.

Характерный признак: После обновления приложение открывает SQLite, но конкретный SELECT/INSERT сообщает no such column: name, хотя таблица существует.

#Как отличить возможные причины

#Пошаговая диагностика и исправление

1. 1. Выпишите полную ошибку и SQL, который её вызвалНайдите в журнале приложение запрос и точное имя поля после no such column. Уточните таблицу и алиасы. Если журнал пишет только код ошибки, включите временное безопасное журналирование шаблонов SQL без персональных данных и паролей.

1. 2. Убедитесь, что вы проверяете ту же базуИспользуйте путь из конфигурации приложения; в sqlite3 проверьте PRAGMA database_list. Если путь отличается от ожидаемого, не создавайте новую схему в неизвестном файле.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Только чтение; возвращает список присоединённых баз и их пути.

   sqlite3 -readonly /srv/app/data/app.db 'PRAGMA database_list;'

1. 3. Получите фактический перечень столбцовДля таблицы, указанной в ошибке, выполните table_xinfo — он показывает также скрытые/генерируемые столбцы, которые обычный table_info может не показывать.
2. orders — имя для примера; результат: порядковый номер, имя, тип и служебные флаги

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   orders — имя для примера; результат: порядковый номер, имя, тип и служебные флаги.

   sqlite3 -readonly /srv/app/data/app.db 'PRAGMA table_xinfo(orders);'

1. 4. Проверьте SQL определения таблицыСравните SQLite-схему с файлом миграции проекта. Если миграция должна добавить поле, узнайте, выполнялась ли она и в каком окружении. Ошибки миграции ищите в журнале развёртывания.
2. Запрос на чтение; выводит CREATE TABLE для выбранной таблицы

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Запрос на чтение; выводит CREATE TABLE для выбранной таблицы.

   sqlite3 -readonly /srv/app/data/app.db "SELECT sql FROM sqlite_schema WHERE type='table' AND name='orders';"

1. 5. Сверьте версии приложения и миграцийПроверьте учёт миграций именно вашего проекта: таблицу migrations, alembic_version, schema_migrations или другой реестр, если он существует. PRAGMA user_version показывает число, только если приложение реально его использует.
2. Не устанавливайте значение вручную: это не выполняет миграцию

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Не устанавливайте значение вручную: это не выполняет миграцию.

   sqlite3 -readonly /srv/app/data/app.db 'PRAGMA user_version;'

1. 6. Исправьте расхождение на копииЕсли столбец действительно переименован, исправьте код SQL с учётом алиасов и тестов. Если миграция не применена, запустите официальную миграцию приложения на копии и проверьте результаты, не составляя наугад ALTER TABLE для рабочей базы.

1. 7. Протестируйте и чтение, и записьЗапустите на тестовой базе именно тот запрос, который падал, и отдельно проверьте INSERT/UPDATE в откатываемой транзакции. Ожидайте отсутствие no such column и правильные данные, а не только успешный старт сервера.

1. 8. Перенесите подтверждённую правку и сохраните откатПеред обновлением сделайте резервную копию, согласуйте время применения миграции и версии кода. После перезапуска приложения повторите проблемную операцию; при ошибке верните согласованную пару «код + схема» по плану отката.

#Как проверить исправление

PRAGMA table_xinfo подтверждает поле, запрос приложения проходит на нужной базе, миграционный реестр и фактическая схема согласованы.

#Если исправление не помогло

Если поле существует, проверьте имя алиаса в JOIN, синтаксис запроса, чувствительность к кавычкам для имён и неоткатанную миграцию в другом окружении.