При работе с платформой 1С:Предприятие 8.3 и использованием расширений конфигурации для модификации функционала, часто возникает необходимость их полного удаления. Однако стандартные методы деактивации и удаления расширения не всегда полностью очищают информационную базу, особенно при ее работе с MS SQL Server. Мы сталкиваемся с тем, что в структуре базы данных остаются так называемые "следы" расширения, которые проявляются в виде таблиц с суффиксом х1 (например, _AccumRgOpt6881х1), и приводят к ошибкам при обновлении конфигурации или дальнейших операциях с базой. Для централизованного контроля и деактивации модификаций можно использовать обработку для управления расширениями и массового отключения.
Разберем подробнее, почему возникают такие проблемы и как их можно успешно решить.
Платформа 1С устроена таким образом, чтобы максимально защитить данные от случайной потери. Когда мы добавляем расширение, которое изменяет структуру данных (например, добавляет реквизиты к существующим объектам или новые объекты, которые затем модифицируются), 1С создает дополнительные структуры в базе данных. В случае MS SQL Server это часто выражается в создании таблиц с суффиксом х1. Эти таблицы содержат данные, относящиеся именно к расширению.
Защита от потери данных: Отключение расширения (снятие признака активности) не приводит к немедленному удалению его структур данных. Оно лишь делает их недоступными. Это позволяет при необходимости повторно активировать расширение и восстановить доступ к его данным. Такая логика, хотя и полезна для безопасности, препятствует полной очистке.
Неполная реструктуризация: При попытке удаления расширения, модифицирующего данные, платформа должна выполнить "обратную реструктуризацию". Этот процесс подразумевает перенос данных из "расширенных" таблиц обратно в исходные таблицы объектов конфигурации (если это возможно) и последующее удаление самих таблиц с суффиксом х1. Однако, этот механизм не всегда срабатывает корректно, особенно в сложных случаях или при наличии специфических ошибок в базе. В результате, таблицы и метаданные, связанные с расширением, остаются, вызывая конфликты.
Мы видим это в сообщениях об ошибках, таких как:
Ошибки SDBL: При попытке объединения конфигураций (например, обновлении) система может выдавать ошибку SDBL Ожидается выражение (pos=1331), указывающую на проблемы с внутренней структурой данных, вызванные оставшимися следами расширения.
Ошибки поиска таблиц: Даже после удаления расширения и ручной чистки таблиц с х1 из SQL, при обращении к некоторым объектам конфигурация может выдавать ошибку о невозможности найти таблицу с суффиксом х1. Это указывает на то, что платформа "помнит" о расширении на уровне метаданных, хотя физически таблицы уже нет.
Сообщения "Тестирования и исправления" (ТиИ): Инструмент "Тестирование и исправление" часто выявляет эти проблемы, сообщая об обнаружении "таблиц расширения конфигурации X1 для объекта, неизмененного расширениями конфигурации", "неиспользуемой таблицы: AccumRgAggDimsX1" или "вспомогательных данных для удаленных расширений конфигурации". Однако, ТиИ не всегда способно полностью удалить эти структуры.
В процессе поиска решения проблемы полного удаления расширения мы рассмотрим несколько подходов, предложенных участниками обсуждения, и проанализируем их эффективность.
Выгрузка/загрузка информационной базы в файл DT.
Этот метод является стандартным для переноса базы и часто рекомендуется при возникновении различных проблем со структурой. Мы можем выгрузить базу в файл .dt через режим "Конфигуратор", затем создать чистую информационную базу (возможно, даже на новом сервере MS SQL) и загрузить в нее наш .dt файл. Предполагается, что при этом платформа перестроит структуру базы данных "с нуля", не перенося информацию о расширениях.
Результативность: К сожалению, в большинстве случаев этот метод не приносит полного решения для проблемы с оставшимися таблицами х1. Мы видим, что при загрузке старого .dt файла на новую конфигурацию (или даже на старую, но уже "очищенную" от `x1` вручную), .dt "затирает" новую структуру и разворачивает свою, которая всё равно содержит то "говно с префиксом х1". Платформа "помнит" о расширении даже после его удаления и после выгрузки/загрузки данных.
Полное удаление базы данных в MS SQL и создание новой.
Этот подход является наиболее радикальным: мы можем просто "убить" существующую базу данных в SQL Server Management Studio и создать новую, пустую. Затем, по идее, можно загрузить в нее .dt файл. Этот метод гарантирует полное отсутствие любых "следов" старой базы, включая расширения.
Результативность: Несмотря на свою "гарантию", этот метод неприемлем для большинства рабочих систем, поскольку ведет к полной потере всех данных. Он может быть полезен только для тренировки на тестовых базах, но не для продакшн-среды, где необходимо сохранить информацию.
Тестирование и исправление информационной базы.
Мы можем использовать встроенный механизм "Тестирование и исправление" в режиме "Конфигуратор" для анализа и потенциального исправления структуры базы данных. Этот инструмент часто помогает выявить и решить многие проблемы.
Результативность: Как мы убедились, "Тестирование и исправление" может обнаружить оставшиеся таблицы расширений (например, "Обнаружена таблица расширения конфигурации AccumRgOpt9988X1"), а также "неиспользуемые структуры хранения расширений конфигурации" и "информацию об именах объектов для удаленных расширений конфигурации". Однако, к сожалению, оно не всегда способно полностью удалить эти объекты или некорректно их обрабатывает, что приводит к сохранению проблемы.
После многих неудачных попыток и анализа различных подходов, участниками сообщества был найден рабочий, хотя и достаточно трудоемкий метод. Мы рассмотрим его пошагово, чтобы вы могли применить его на практике.
Важно: Перед выполнением любых операций по изменению структуры базы данных, обязательно создайте полную резервную копию информационной базы! Это позволит нам восстановить работоспособность системы в случае возникновения непредвиденных проблем.
Создайте полную резервную копию информационной базы.
Мы можем сделать это как средствами 1С (через выгрузку в .dt файл), так и средствами MS SQL Server (полный бэкап базы данных). Убедитесь, что копия работоспособна.
Перенесите информационную базу из серверного режима (MS SQL) в файловый режим.
Это ключевой шаг. Мы создаем новую, пустую файловую базу 1С. Затем, из конфигуратора, мы выгружаем данные из нашей серверной базы в файл .dt. После этого мы загружаем этот .dt файл в созданную нами файловую базу. Переход в файловый режим часто позволяет механизмам реструктуризации 1С работать более надежно, так как файловая база имеет более простую структуру хранения данных, что может способствовать более полному удалению метаданных расширений.
Удалите расширение конфигурации в файловой базе.
В открытой файловой базе перейдите в режим "Предприятие". Откройте список расширений конфигурации (обычно через меню "Все функции" или "Администрирование"). Сначала снимите флажок "Активно" для расширения, которое мы хотим удалить. Затем удалите само расширение из списка. После этого перейдите в режим "Конфигуратор" и обязательно примите изменения структуры базы данных. Этот шаг критически важен, так как он запускает процесс "обратной реструктуризации" и очистки таблиц расширения. В файловом режиме эта операция имеет больше шансов на успех.
Выполните "Тестирование и исправление" файловой базы.
После удаления расширения и принятия изменений, запустите "Тестирование и исправление" для нашей файловой базы. Мы должны убедиться, что инструмент больше не находит никаких следов удаленного расширения, таких как таблицы х1 или вспомогательные данные. Если отчет ТиИ чист, это хороший знак.
Верните информационную базу обратно в серверный (MS SQL) режим.
Теперь, когда файловая база очищена от расширения, мы можем перенести ее обратно на MS SQL Server. Выгрузите файловую базу в файл .dt. Создайте новую, пустую базу данных на MS SQL Server. Затем загрузите в нее наш .dt файл. Этот шаг восстановит базу на сервере, но уже без следов расширения.
Проверьте базу данных в MS SQL Server.
После загрузки базы на SQL Server, мы можем подключиться к ней через MS SQL Server Management Studio и убедиться, что таблицы с суффиксом х1, которые ранее вызывали проблемы, теперь отсутствуют.
Восстановление данных (при необходимости).
В некоторых случаях, как это было упомянуто в сообщении 18, при таком переносе может потребоваться восстановление части "битой" информации. Если вы обнаружите, что некоторые данные были потеряны или повреждены, вы можете использовать ранее сделанную резервную копию или, как было предложено, "дергать" данные из битой базы через выгрузку XML обработкой. Это сложный процесс, требующий глубокого понимания структуры данных.
Для успешного и безопасного выполнения процедуры удаления расширений мы рекомендуем учитывать следующие моменты:
Осторожность при ручной чистке служебных таблиц SQL: В крайне редких и сложных случаях, когда стандартные методы не помогают, некоторые специалисты прибегают к ручной очистке служебных таблиц 1С в MS SQL Server, таких как _ExtensionsInfo, ConfigCAS и ConfigCASSave. Удаление данных из этих таблиц может временно решить проблему, но это чрезвычайно рискованная операция. Она может привести к необратимому повреждению базы данных и должна выполняться только опытным специалистом с предварительным созданием множественных резервных копий.
Консультация с разработчиком: Если расширение является сложным или было разработано сторонней организацией, мы рекомендуем обратиться к его разработчику. Они могут предоставить специфические инструкции по безопасному удалению, учитывая особенности воздействия расширения на структуру данных.
Важность резервного копирования: Мы еще раз подчеркиваем, что создание полной резервной копии информационной базы перед началом любых манипуляций с расширениями или структурой данных является обязательным условием. Это ваша страховка от непредвиденных ситуаций.
Привлечение квалифицированных специалистов: Если вы не уверены в своих силах или сталкиваетесь с особо сложными случаями, мы настоятельно рекомендуем привлечь квалифицированных специалистов по 1С. Их опыт поможет избежать ошибок и сохранить целостность ваших данных.
Таким образом, мы видим, что для полного и безопасного удаления расширения 1С и его следов из базы данных на MS SQL Server требуется комплексный подход, часто включающий в себя перенос базы в файловый режим для выполнения очистки. Мы призываем вас действовать осторожно и всегда иметь актуальные резервные копии. Для анализа соответствия объектов метаданных и физических таблиц СУБД можно использовать инструмент для исследования структуры хранения базы данных.