Решаемая обработкой проблема появилась при обновлении в релизах платформы 8.3.15
О природе ее возникновения можно только догадываться, поскольку на более поздних релизах такая ситуация не является ошибкой.
Дело в том, что начиная с указанного релиза 1с при проверке состояния базы проверяет, уникальность каждого номера таблиц, а до этого, для "правильности" было достаточно, чтобы уникальность сохранялась для отдельного вида таблиц. Т.е. проверялась отдельно уникальность для справочников, документов, регистров и прочее... Какой из релизов платформы напортачил при обновлении конфигураций неясно, но релиз довольно древний.
Обработка позволяет исправить схему имен базы данных, схема которой была испорчена, и тем самым устраняет ошибки при обновлении конфигурации или при сервисной процедуре тестирования и исправления. Следует отметить, что пока эта ошибка не мешает работе программы, а проявляется только при работе в конфигураторе.
Если вы словили такую ошибку:
**************************
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом ....
**************************
Далее перечисляются пары таблиц, которые имеют одинаковый номер.
То эта обработка должна помочь. Запускать ее можно в любой базе на управляемых формах, только не в той, что исправляется.
Шаг 1. Указать параметры доступа к базе SQL. Перейдите на вторую закладку
Шаг 2. Файлы исходной базы. Под файлами понимаем текст имен и текст схемы. На рис. 2 показаны как они выглядят, но на этом шаге поля будут пустыми, их заполнит обработка после нажатия на указанную кнопку. Обработка считывает схему прямо через sql-запрос.
Шаг 3. Таблицы корректировки номеров. Пользователю требуется для каждой пары определить таблицу, которую он будет перенумеровывать. Требуется указать тип таблицы и тот злополучный неуникальный ссылочный код. Новый ссылочный код обработка укажет сама, после выполнения этого шага можно вернуться и посмотреть его. На рисунке 3 ссылочный код уже указан для наглядности, но при первом прохождении эту колонку заполнять не нужно. Он сохранился на рисунке, т.к. вся таблица сохраняется автоматически. В любом случае этот номер будет обновлен выполнением команды по кнопке. В этой версии добавилась возможность отметить те строки которые будут участвовать, остальные сохранятся, но участвовать не будут. На этом шаге обработка формирует новые файлы схемы. При выборе в паре таблицы для переномерования предпочтение следует отдавать перечислениям, константам.
В нижней таблице будут добавлены строки с именами таблиц табличных частей.
Рекомендуется в случае подобных пар:
Имена таблиц с кодом 28: BPrPoints28, ExtensionsRestructNGS
Совершенно безопасно разлепить эту пару второй таблицей. В схеме она не числится, нашел свободный код 16 и заменил вручную в таблице имен. Никаких переименований таблиц базы не потребуется:
{00000000-0000-0000-0000-000000000000,"ExtensionsRestructNGS",16},
Кстати, эти особенные таблицы, их не надо обрабатывать "переименованиями", да у них и номера нет, только для порядка в файле имен.
Т.е. такие пары в таблицу не вставлять, исправить файл имен самостоятельно.
Шаг 4. Можете посмотреть новые файлы схемы, а в сообщениях можно увидеть протокол замен. Ну и по команде нужно записать в базу SQL обновленную схему. А потом по команде подготовить SQL-запрос для переименования таблиц.
Шаг 5. Выполнить команды SQL. Подготовленный список операторов переименует таблицы.
На этом работа обработки заканчивается. Исправленную Базу следует проверить в конфигураторе. Администрирование, Тестирование и исправление, пункт Реструктуризация информационной базы. Эта процедура переименует все индексы обработанных таблиц, а так же статистики таблиц.
Поскольку 1с может использовать кэш, а в этом кэше может сохраниться старая схема, то следует либо освободиться от кэша (сервера и клиента), либо (как некоторые освобождаются от кэша) удалить базу без изменения базы SQL, а потом создать новую базу с указанием на прежнюю базу SQL. У меня в конфигураторе конфигурация была закрыта, кэш мне не помешал.
В общем случае, даже ошибка в таблице на шаге 3 не должно приводить к порче схемы (базы), просто если указать не ту таблицу (тип и номер) она будет переименована и в схеме и в базе, что не возбраняется. Просто проблема не устранится.
Предупреждение об ответственности.
Использование обработки только под Вашу ответственность, не забывайте про бэкапы и тестирование результатов. Не исключена ситуация, которая не учитывает данная версия обработки и методики, которую она реализует.
P.S. оказалось не понятно из описания и следует сфокусировать внимание:
1. Запускать обработку нужно в другой базе, не в той, которую исправляете. Обработка работает непосредственно с MS SQL, а не с базой текущего приложения.
2. Если основная конфигурация изменена, то нужно вернуться к конфигурации базы данных.
3. Для результата нужно обрабатывать сразу все пары, нет смысла устраивать цикл запусков обработки.
Благодарности:
Обработка создавалась по мотивам методики следующей публикации:
//infostart.ru/public/1126277/ Именно эту методику обработка автоматизирует. Руками у меня получилось криво. Благодаря чему и создал обработку.
Подсмотрены алгоритмы в приобретенной обработке:
//infostart.ru/public/1018320/
Обработка тестировалась на релизе платформы: 1С:Предприятие 8.3 (8.3.15.1830).
