При активном внедрении механизмов расширений в платформу «1С:Предприятие 8.3» разработчики часто сталкиваются со специфическим поведением системы при обновлении конфигурации базы данных. Одна из наиболее коварных и критических ошибок возникает при попытке добавить новые физические таблицы (например, регистры накопления) в расширение конфигурации на клиент-серверных базах под управлением СУБД MS SQL Server.
В процессе обновления базы данных система аварийно завершает работу, выдавая следующее сообщение:
В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка при получении значения из базы данных. Возможной причиной является отсутствие установленного Microsoft SQL Server Native Client.
При этом на файловой копии базы данных то же самое обновление может проходить абсолютно беспрепятственно и без единой ошибки. В данной статье мы подробно разберем, почему возникает этот сбой, проанализируем технические нюансы работы платформы с СУБД и рассмотрим надежные варианты решения этой проблемы.
Начнем с того, что текст сообщения об отсутствии драйвера Microsoft SQL Server Native Client в 99% случаев вводит администраторов и разработчиков в заблуждение. На самом деле драйвер в системе установлен и исправно работает, что подтверждается успешным запуском и обновлением других информационных баз на этом же сервере.
Данное предупреждение является универсальной «заглушкой» платформы 1С. Она выводится в тех случаях, когда на уровне СУБД происходит глубокий критический сбой транзакции реструктуризации, который платформа не способна корректно распознать и детализировать для пользователя. Рассмотрим подробнее, из-за чего именно происходит этот сбой:
tempdb. Если СУБД возвращает ошибку блокировки или несовместимости типов, вся транзакция откатывается. При этом целостность системной схемы данных метаданных в 1С нарушается, платформа «теряет» контекст соединения с SQL-сервером и рапортует об отсутствии Native Client.Иногда разработчики пытаются обойти подобные сбои сомнительными методами. Рассмотрим пример, когда базу данных удается запустить, закомментировав проверку версии платформы в коде Библиотеки Стандартных Подсистем (БСП). В общем модуле СтандартныеПодсистемыСервер в процедуре ПередЗапускомПрограммы вносится следующее изменение:
// Если ЗначениеЗаполнено(НеПоддерживаемаяВерсияПлатформы) Тогда
// ВызватьИсключение СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(
// НСтр("ru = 'Режим совместимости конфигурации с 1С:Предприятием версии %1 не поддерживается...'"));
// КонецЕсли;
Важное предупреждение: применение таких обходных путей критически опасно! Отключение проверок БСП позволяет запустить сеанс программы в обход предупреждений безопасности системы. Однако сама база данных при этом остается в физически разрушенном состоянии. Физические таблицы расширения на уровне MS SQL Server создаются некорректно или не создаются вовсе. В дальнейшем это неизбежно приведет к скрытому повреждению данных (data corruption): при попытке проведения документов, делающих движения по новому регистру накопления, система начнет выдавать непредсказуемые ошибки или просто безвозвратно терять информацию.
Ниже мы разберем правильные и безопасные шаги по устранению проблемы.
В профессиональном сообществе разработчиков 1С размещение тяжелых физических таблиц (таких как справочники, документы и регистры накопления), в которых будут накапливаться критически важные транзакционные данные бизнеса, внутри механизмов расширений считается крайне рискованным шагом. При любом крупном обновлении конфигурации, платформы или при повреждении кэша расширение может «слететь» или заблокироваться, что приведет к моментальной потере накопленных данных. Чтобы минимизировать такие риски при администрировании нескольких баз, можно настроить их автоматическое архивирование и тестирование перед обновлением.
Для реализации безопасной архитектуры выполним следующие шаги:
Если бизнес-требования обязывают вас хранить регистр накопления именно в расширении, то использовать платформу ветки 8.3.13 категорически запрещено. Ранние релизы этой ветки не приспособлены для стабильной работы с расширениями данных на SQL.
Для решения проблемы необходимо выполнить обновление платформы до актуальных и стабильных релизов (например, ветки 8.3.15, 8.3.20 или выше, в зависимости от требований используемой конфигурации). В новых версиях платформы разработчики 1С исправили множество критических багов реструктуризации физических таблиц расширений на MS SQL Server.
Иногда реструктуризация прерывается из-за того, что СУБД физически не может завершить создание тяжелых индексов и таблиц итогов регистра накопления по причине ограничений дискового пространства или настроек памяти. Для регламентного обновления статистики и перестроения индексов таблиц можно использовать обработку для обслуживания баз SQL средствами 1С.
Разберем шаги по настройке MS SQL Server:
.ldf) и убедимся, что для него отключено жесткое ограничение на максимальный размер файла (параметр Autogrowth / Maxsize). При реструктуризации лог может лавинообразно увеличиваться в размерах. Установим параметр ограничения размера файла в положение Unlimited (Неограниченно) или выделим под него достаточный объем свободного пространства на диске.0, временно увеличим его (например, до 8 GB или более, в зависимости от доступной оперативной памяти сервера), чтобы процесс реструктуризации не завершался принудительно менеджером кластера 1С.Если вы уже удалили проблемное расширение, но база данных по-прежнему выдает ошибку при обновлении или запуске, это означает, что старая разрушенная схема метаданных зависла в кэше сервера приложений 1С.
Для исправления этой ситуации выполним полную очистку кэша сервера по шагам:
services.msc) или с помощью команды в консоли:
net stop "1C:Enterprise 8.3 Server Agent"
C:\Program Files\1cv8\srvinfo\).reg_1541). Внутри нее будут располагаться каталоги с уникальными идентификаторами баз данных (UID).snccntx... (это кэш сеансов данных) и папки временных файлов внутри каталогов баз данных.
net start "1C:Enterprise 8.3 Server Agent"
После очистки кэша сервер 1С заново перечитает физическую структуру метаданных непосредственно из таблиц MS SQL Server, что позволит успешно запустить базу данных.
Мы проанализировали особенности работы регистров накопления в расширениях баз данных 1С на MS SQL. В качестве превентивной меры мы настоятельно рекомендуем переносить структуру физических таблиц в основную конфигурацию, а в расширениях оставлять только бизнес-логику. Если же использование таблиц в расширениях неизбежно — обязательно обновите платформу 1С до стабильных современных версий и следите за объемом свободного места для файлов транзакций на SQL-сервере.