При работе в команде через хранилище конфигурации 1С программисты часто сталкиваются с крайне неприятной ситуацией: после получения изменений из хранилища новые реквизиты или объекты вроде бы появляются в дереве метаданных, но при попытке обращения к ним в режиме «1С:Предприятие» система выдает ошибку SDBL или просто «не видит» обновленные данные. В некоторых случаях реквизиты могут исчезать даже из форм, оставляя после себя пустые привязки.
В этой статье мы подробно разберем причины этого явления, проанализируем механизмы работы платформы 8.2 и 8.3 с базой данных SQL и составим пошаговый план решения проблемы, чтобы ваши данные больше не «исчезали».
Рассмотрим основной механизм, который приводит к ошибкам. Главным виновником здесь выступает так называемое «динамическое обновление» (обновление конфигурации базы данных без выгона пользователей). Когда вы получаете изменения из хранилища и нажимаете кнопку «Обновить конфигурацию базы данных», платформа предлагает выполнить обновление динамически, если в базе есть активные сеансы.
Проанализируем, что происходит внутри системы в этот момент:
Config в базе данных SQL, записывая туда новую структуру метаданных.Выясним причину странного поведения, когда изменения то появляются, то исчезают. Это связано с тем, что конфигуратор в одной сессии может считать структуру обновленной, а сервер 1С в другой сессии продолжает использовать старую версию кэша метаданных. В результате возникает «эффект призрака»: реквизит виден в конфигураторе, но отсутствует в реальности.
Разберем ситуацию, когда очистка кэша становится жизненно необходимой. Локальный кэш конфигуратора хранит промежуточные состояния объектов. Если кэш поврежден, то при получении данных из хранилища сопоставление объектов (ID метаданных) может пройти некорректно.
Особое внимание стоит уделить случаям, когда конфигуратор запускается под системной учетной записью или в специфическом RDP-окружении, как упомянул автор темы. Если у пользователя нет полных прав на запись в папку своего профиля или если кэш «виртуализируется» операционной системой, 1С не может корректно обновить временные файлы. Это приводит к тому, что после закрытия и открытия конфигуратора изменения «откатываются» или отображаются некорректно.
Если вы столкнулись с ошибкой SDBL или отсутствием полей после хранилища, нам необходимо заставить 1С физически перестроить таблицы базы данных. Выполним это по шагам:
ТестовыйРеквизит с типом Строка или измените длину существующего текстового реквизита (например, комментария) на 1 символ.Этот метод гарантированно пересчитывает соответствие между метаданными 1С и колонками таблиц SQL Server.
Рассмотрим подробнее, какие именно папки нужно очистить. На клиентской машине (или на сервере, где запускается конфигуратор) необходимо удалить содержимое следующих директорий:
Для Windows 7, 10, 11 и Windows Server 2012+:
%AppData%\1C\1Cv82 (или 1Cv8 для версии 8.3)%LocalAppData%\1C\1Cv82 (или 1Cv8 для версии 8.3)Внутри этих папок находятся каталоги с длинными именами-идентификаторами (GUID). Именно в них хранится закэшированная конфигурация. Удалять эти папки можно смело — при следующем запуске 1С создаст их заново, получив актуальные данные из информационной базы.
Если используется серверный вариант базы, также рекомендуется остановить службу 1C:Enterprise Server и очистить серверный кэш, который находится в папке snccntx внутри каталога данных сервера (обычно это C:\Program Files\1cv8\srvinfo).
Иногда корень зла кроется в самом файле хранилища. Если во время помещения объектов (Сommit) произошел сетевой сбой, версия объекта в хранилище может оказаться «битой». Проанализируем, как это исправить:
Чтобы избежать подобных проблем в будущем, мы рекомендуем придерживаться следующих правил:
Full Control на папки Temp и профиль пользователя на сервере.Проанализировав ситуацию, можно сделать вывод: проблема не в «глюках» хранилища как такового, а в рассинхронизации уровней кэша и физической структуры БД. Использование фиктивной реструктуризации и регулярная очистка кэша позволяют полностью устранить эти ошибки.