Если вы не спец в работе с базами 1С, то можете при обновлении допустить простую ошибку: вместо того, чтобы запустить процедуру объединения (при которой система анализирует различия в структуре данных), заменяете файл конфигурации новым, просто записывая его поверх старого. Наиболее велик соблазн поступить таким образом в случае с локальной базой в файловом варианте, т.е. когда все данные хранятся в файлах DBF. Вот на таком примере и расскажу, что бывает и как это исправить.
Итак, после замены файла 1cv7.md новым вариантом при запуске 1С:Предприятия видим примерно такое сообщение: «Codebase error, Unrecognised Field Name…»
И за ним например такое: «Нарушена структура данных таблицы …»
Эти сообщения говорят о том, что при открытии файлов базы система обнаруживает, что их структура, т.е. названия или параметры полей в таблицах, не соответствует тому, что она ожидает увидеть. А понять, что она хочет видеть очень просто: структура данных описана в текстовом файле, который находится в одной папке с файлом конфигурации, он называется 1cv7.dd. Открыв этот файл, например стандартным Блокнотом, и выполнив поиск по названию таблицы DH553, можно обнаружить, что речь идет о документе Калькуляция, кроме того, здесь видно что ошибка в шапке документа, т.к. его табличная часть хранится в файле DT553 – это тоже видно в описании структуры.
Первое сообщение указало на ошибку в имени поля: SP2867, это поле есть в списке полей упомянутой таблицы документа Калькуляция, значит теперь нужно заглянуть непосредственно в файл DH553.DBF. Для просмотра содержимого, а главное и структуры DBF-файлов я использую программу WinDBFView (ее можно легко найти поиском по названию, например тут: ссылка). Открыв описание структуры DBF файла и сравнивая ее с описанием в файле 1cv7.dd вижу, что на месте нужного поля SP2867 находится поле SP2868. Теперь закрываем просмотр DBF, в файле 1cv7.dd, в текстовом редакторе исправляем название поля на то, которое есть в файле, т.е. SP2867 на SP2868, сохраняем и закрываем. Теперь, если других ошибок в структуре нет, база должна нормально открыться. Однако если в таком виде попытаться что-то изменить в конфигурации и сохранить изменения – система сгенерирует “неисправленный” файл структуры и ошибка снова появится. Так что для окончательного исправления необходимо в конфигураторе удалить ошибочный реквизит, сохранить изменения, а потом вернуть его на место. При такой манипуляции 1С изменит структуру DBF-файла и уже его структура будет в порядке, но (!) данные этого реквизита будут утеряны.
Логика приведенного примера проста: анализируя файл описания структуры данных и сами данные нужно сначала подогнать описание структуры под имеющиеся данные, а потом уже в конфигураторе сделать откат изменений, т.е. вернуть реквизиты в то состояние, которое было описано в структуре до ручных исправлений. И, конечно, не забывайте про резервные копии, всего этого можно избежать просто восстановив базу из копии, сделанной перед обновлением.