Исправление ошибки "Для одного ссылочного кода существует более одной таблицы в базе данных"
Задачи пользователя - Корректировка данных
Отказ от ответственности: вы все здесь взрослые и делаете всё на свой страх и риск. Да, и ещё: лицензионное соглашение не разрешает вам это делать, поэтому данное описание дано для образовательных целей.
После перехода с 8.3.12 на 8.3.15 словили неприятную ошибку "Для одного ссылочного кода существует более одной таблицы в базе данных". Самое неприятное, что ошибка стала вылезать и на типовых базах, которые никто никогда не трогал.
Гугл ничего не дал кроме стандартных "почистить кэш, перерегистрировать базу в кластере, выполнить ТИИ". Ну и еще "добавить реквизит к объекту и обновить БД" (этот пункт не пробовал, напишите в комментариях - вдруг это самый простой метод в комментариях к этой статье есть сообщение что метод сработал на 8.3.16.1030, пробуйте). Upd: на данный момент это самый простой и эффективный способ, рекомендую. Но он не работает например для перечислений т.к. у них нет реквизитов.
Другой вариант из комментариев - создать копию базы через РИБ. В копии проблема ушла: "Создал узел для базы (РИБ), потом отвязал эту базу от основной".
Дальше читаем если простой способ не помог.
На партнерке есть пара веток, в т.ч. https://partners.v8.1c.ru/forum/topic/1792992, из которой приведу пару цитат:
Воспроизводится так (проверено на релизе 8.3.13.1644 / SQL 2016):
1. Создаём две базы test1 и test2
2. Запускаем конфигуратор test1, добавляем справочник, обновляем конфигурацию. В базе добавляется таблица _Reference21
3. Делаем SQL бэкап базы test1 и восстанавливаем его в test2.
4. Запускаем конфигуратор test2 и добавляем документ, обновляем конфигурацию. В базе видим таблицы: _Reference21 и _Document21.
Помогает перезапуск rmngr.exe после восстановления test2 из бэкапа.
И ответ представителя фирмы 1С:
Да, действительно, в этом сценарии две таблицы получают два одинаковых ссылочных номера.
Это ошибка, будет исправлена в одной из следующих версий.
Что можно сказать по этой ошибке. Во-первых, чистка кэша не поможет. Во-вторых, ошибка воспроизводится только если было хотя бы одно добавление объекта метаданных до восстановления из резервной копии (это приводит к инициализации сервиса в менеджере кластера, и как следствие - сохранению значения последнего номера таблицы).
Рекомендации на сейчас (до выхода версий с исправлением) по обходу ошибки: сразу после восстановления ИБ средствами СУБД - производите перезапуск сервера платформы.
Я провел тест на 8.3.12 - проблема по методике первой цитаты воспроизводится. Так что делаю выводы:
1) проблема с задвоением внутренней нумерации объектов существовала очень давно, как минимум с 8.3.12, но лишь в 8.3.15 добавили проверку (понятно) и запрет применения изменений (а вот тут явно не подумали что у пользователей много таких "поломанных" баз)
2) по-идее, можно жить спокойно на релизах менее 8.3.15 и ждать манны небесной от фирмы 1С.
Ну а нам ждать "одной из следующих версий" нельзя. Базы разработчиков "встают" одна за другой на этой ошибке. Я предлагал откатиться на 8.3.13 или 8.3.14 - но согласился пробовать найти свое решение, т.к. когда будет эта "манна" - неизвестно. А если продолжить использовать "старые" релизы - то дубли нумерации скорее всего будут только плодиться, хоть мы их и не будем видеть.
Размышления привели к пониманию того, что надо найти "где в базе хранится сопоставление таблиц sql и объектов конфигурации". Как оказалось таких мест два: таблица DBSchema и реквизит DBNames таблицы Params.
Попытка получить DBSchema использованием SQL Management studio завершилась неудачей: в режиме ssms получается получить лишь первые 65КБ двоичных данных, хранящихся в таблице, и при вставке в hex-редактор получаем неполную структуру.
А уж DBNames и вовсе хранится в сжатом виде. Поэтому усилия были перенаправлены на поиск инструмента для редактирования этих данных. И он был найден: Восстановление структуры DBSchema
Стоимость инструмента - 10sm (Мопед не мой!). Впрочем, описанная ниже методика не зависит именно от этой обработки; можете поискать аналог или написать свою. Функционал указанной обработки используется только в части выгрузки DBSchema и DBNames из sql в файл и обратно.
А я опишу методику лечения баз:
- рекомендуется использовать Notepad++ или аналог. В отдельном файле открыть текст ошибки из конфигуратора.
- запустить обработку, получить DBSchema (схема - список объектов - распознать схему) и DBNames (вверху "загрузить из БД в файл"), выгрузить обе структуры в файлы, указав вверху пути и нажав на кнопки "выгрузить схему из списка в файл" и "загрузить из БД в файл". Открыть файлы в Notepad++, выставить синтаксис "С/С#" (или иной - для удобства сворачивания групп). Должно получиться примерно следующее (слева DBNames, справа - DBSchema):
- из текста ошибки для каждой пары объектов выбрать "жертву"; проще менять номер у констант или регистров, т.к. на них обычно нет ссылок в реквизитах других объектов. Желательно выбирать в таком качестве "таблицы изменений" вида _ConstChngR2346 или _DocumentChngR3078 не имеющие табличных частей (у нет таблиц вида Document750.VT20237 или _Reference49197_VT3332).
- в DBNames находим строку жертвы по номеру объекта, переносим строку в конец файла, меняем номер объекта (+1 к предыдущему)
- в файле с текстом ошибки к номеру "жертвы" добавляем "-НовыйНомер"
- в DBSchema находим объект, меняем номер объекта (в третьем параметре); ищем все вхождения имени объекта (например Reference3048) - ссылки на этот объект в реквизитах других объектов - выполняем замену например Reference3048 на Reference49189.
- в DBNames первый параметр меняем на новый максимальный номер объекта
- сохраняем файлы, считываем их обработкой (вся схема - текст - прочитать схему из файла, Имена - Прочитать DBNames из файла), выгружаем из обработки в БД
- пишем sql-код для переименования всех таблиц вида:
EXEC sp_rename _Enum3066, _Enum49200
EXEC sp_rename _Enum3067, _Enum49201
EXEC sp_rename _DocumentChngR3078, _DocumentChngR49202
и выполняем его. Если все-таки жертвой был справочник с табличной частью - во всех табличных частях надо переименовать ссылку
EXEC sp_rename '_Reference49197_VT3332._Reference3048_IDRRef', '_Reference49197_IDRRef', 'column'
- после выполнения указанных действий также рекомендую удалить-добавить базу в кластере.
Хотя от представителя 1с на партнерском форуме есть альтернатива - рекомендация перезапускать сервер - в комментариях (7) к данной статье коллега отписался о неэффективности этого метода.
upd 24.01.2020: рекомендую ознакомиться с обработкой из комментария 39.
Понравилась статья? Поставь плюс. Рекомендую другие статьи:
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Поиск данных Инструменты администратора БД Корректировка данных Разработчик Бухгалтер Пользователь 1С:Предприятие 8 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 Россия Платные (руб)
Решение для автоматической сверки данных между любыми конфигурациями 1С. Помогает контролировать и проверять обмены, проверять наличие документов при переносах данных, находить изменения в закрытых периодах
9760 руб.
14.11.2025 6231 28 8
Задачи пользователя Инструментарий разработчика Корректировка данных Закрытие периода Разработчик Аналитик Бухгалтер Пользователь Руководитель проекта Стажер 1С 8.3 1С:ERP Управление предприятием 2 1С:Управление нашей фирмой 3.0 Управленческий учет Платные (руб)
Обработка предназначена для поиска, анализа и исправления отрицательных остатков во всех регистрах накопления информационной базы 1С.
6100 руб.
27.02.2026 3254 19 3
Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтер Пользователь 1С:Предприятие 8 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)
Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).
14640 руб.
29.04.2020 53015 146 164
Зарплата Корректировка данных Бухгалтер 1С 8.3 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет НДФЛ Платные (руб)
Внешняя обработка сравнивает НДФЛ из расчетного листка и НДФЛ из регистра, на разницу формирует операцию учета НДФЛ. Исправляет расхождения, в том числе, когда Аванс больше Зарплаты Рассчитывает НДФЛ и сравнивает с исчисленным в программе. На отклонение формирует документ "Перерасчет НДФЛ"
9760 руб.
01.09.2023 10153 325 93
Корректировка данных Разработчик Пользователь 1С:Предприятие 8 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Управленческий учет Платные (руб)
Представьте, что есть система QR - кодирования, которая НЕ ТРЕБУЕТ изменения конфигурации, НЕ ТРЕБУЕТ изменения ни одной печатной формы для добавления QR-кода, включая внешние, НЕ ХРАНИТ данные штрихкодов и их связь, от чего база не "пухнет", ИМЕЕТ возможность закодировать в QR-коде произвольные данные параметров для последующей обработки полученных данных, УМЕЕТ прикреплять сканы, УМЕЕТ обработать считанный QR-код как ВЫ захотите. А также ХРАНИТ историю операций в обход базы для каждого пользователя в отдельности и УМЕЕТ работать с 2D - сканерами. А также автоматически распознавать отсканированные печатные формы (картинки или pdf-файлы) и выполнять заданные произвольные алгоритмы, в том числе прикрепление их к документам! Обновление 3.3 от 24.06.2025!
26840 руб.
26.08.2018 57682 20 65
Файловый обмен (TXT, XML, DBF), FTP Поиск данных Инструменты администратора БД Корректировка данных Системный администратор Разработчик 1С:Предприятие 8 1C:Бухгалтерия 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)
Данная обработка позволит Вам легко и просто, а главное - быстро, выполнить сравнение данных между ЛЮБЫМИ базами (и РИБ, по правилам конвертаций) по контрольным суммам выбранных объектов баз 1С, работающих на платформах 8.3 и выше. Удобный и понятный интерфейс в виде "мастера". Высокая скорость сравнения достигается за счет специального алгоритма расчета контрольной суммы объекта/записи и сравнения по данным суммам объектов 2х баз через файл. Имеется возможность выбора реквизитов, по которым система будет сравнивать объекты. Сравнение количества записей в движениях документов, возможность сравнивать данные по правилам конвертации и не только! Выбор объектов конфигурации для КАЖДОГО узла в отдельности с индивидуальным отбором для каждого объекта конфигурации, работа с FTP, сохранение или загрузка настроек, сохранение или загрузка результата сравнения, регистрация на обмен объекта и его движений. (Обновление от 12.11.2024, версия 2.2-2.5)
24400 руб.
27.10.2017 47895 33 15
Корректировка данных Системный администратор Разработчик Аналитик Бухгалтер Пользователь Руководитель проекта 1С:Предприятие 8 1С:Управление торговлей 11 1С:Розница 3.0 1C:ERP 1С:ЗУП 1С:УТ Платные (руб)
Инструмент для анализа и устранения битых записей в регистрах 1С:Предприятия. Позволяет поддерживать целостность данных и повышает стабильность работы системы. Обработка предназначена для диагностики и корректировки ошибок в регистрах накопления и сведений. Обеспечивает контроль корректности данных и упрощает администрирование информационной базы. Решение для автоматизированного выявления и исправления записей в регистрах 1С. Снижает вероятность сбоев при расчётах и формировании отчётности.
5490 руб.
05.09.2025 2220 4 0
Корректировка данных Системный администратор Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)
Незаменимая обработка для сопровождения конфигураций: ERP, УТ, КА. Позволяет вычистить многие ошибки в ключах аналитики, в ключевых справочниках конфигурации.
6100 руб.
10.02.2017 122766 737 177
- Тестирование и исправление на уровне конфигуратора - результат: долго проверяет и в итоге вываливает ту же самую ошибку без исправления;
- Выгрузка базы в Dt –файл и загрузка его в чистую базу – ошибка не исчезает;
- Выгрузка базы в Dt –файл и загрузка в файловый вариант – ошибка не исчезает;
- Установка Postgre и загрузка данных туда из Dt –файла, снова выгрузка в Dt –файл и загрузка в базу на SQL север;
- Тестирование встроенным проверщиком утилитой chdbfl - тоже ничего не нашло и ошибку не исправило.
При всех этих вариантах структура базы переносилась с ошибкой и ничего не менялось.
Что помогло
купили обработку:
Однако, в ней нет инструкции, что и как, по чату с разработчиком удалось восстановить целостность базы данных. Обработка помогла, база восстановлена. Рекомендую провести восстановление на копии базы, А затем, когда уже будут готовые текстовые файлы с исправленным содержимым для DBNames и СхемаБазы - просто обновить эти таблицы из этих файлов и после сделать запрос: sp_rename _ReferenceХХXX, _ReferenceYYYY - где ХХХХ номер с задвоением таблиц, YYYY - следующий свободный порядковый номер в таблице имен.
Если ошибок несколько, то по каждой надо отдельно вносить корректировки.
Вносить корректировки лучше через автопоиск и автозамену, т.к. малейшие неточности приведут к тому, что при открытии базы получите надпись "Ошибка открытия потока" и восстановить базу можно будет только с бэкапа SQL
За тем, как именно это делается обращайтесь к разработчику или пишите в личку, вышлю свою инструкцию что и как делал.
Зафиксировано исключение из подпункта 1.
ТиИ помогло, НО оно должно быть провоедено в файловом формате и на новой платформе (в моем случае на 8.3.15.1778)
потом нужно на файловой же завершить обновление и только потом через dt в клиент-серверный вариант
ЗЫ был переход УПП 1.3.128.2 -> 1.3.129.1 была только 1 конфликтующая пара (документ (осн. табл) и регистр сведений (также осн. табл)) база 0,9 Gb в файловом формате
В решении от user646807_kazako.a911 предложено поменять UUID на произвольный. Не на правильный (которого -то и нет, т.к. проблема не в UUID), а на какой-то там любой.
Тем более сомнительна рекомендация "В файле "ConfigDumpInfo" UUID объекта можно не менять.". Т.е. в одном месте конфигурации у документа будет один идентификатор, а в другом - другой. На мой взгляд так получаем битую конфигурацию. То, что метод сработал на одной базе скорее всего является следствием лишь того, что в ней указанный документ не использовался.
В решении Дмитрий74Чел приведены несколько вариантов, как сложных (с заменой номеров объектов), так и простых и 100% безопасных (временное добавление объекту реквизита).
Если в посте выше ошибка конкретно указывает на действительно существующие объекты где номер одинаковый, то у нас например вообще не понятно что именно не нравится конфигуратору и платформе...
"В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом 18: DataHistoryVersions, Reference18
Имена таблиц с кодом 19: DataHistoryLatestVersions, Reference19
Имена таблиц с кодом 20: DataHistoryMetadata, Reference20
Имена таблиц с кодом 21: DataHistorySettings, Reference21
Для исправления проблемы вы можете обратиться в службу технической поддержки."
Я не наблюдаю в первых ссылках на всякие инструменты хранения истории хоть какой то нумерации, к тому же инструментарий хранения историй полностью выключен... 1С пока что работает под пользователем.
Добавление реквизитов к выше упомянутым справочникам вообще в принципе ничего не дает... Натолкните куда копать и как решать ? Платформа по сути ругается на все то что связано с инструментом истории данных...
направьте куда копать....
В моем случае помогло ПОМИМО добавки временных реквизитов к данным объектам еще смена режима совместимости в конфигураторе на "Версия 8.3.10"
Может кому то поможет... После данных манипуляций конфигурация обновилась без ошибок.
Руслан, у меня похожая ситуация, попытался проделать так же как и вы, но не получилось.
Конфигурация "Рарус:Альфа-авто v.5", использовалась на платформе 8.3.13. В свойствах у нее установлен родной (от разработчиков) режим совместимости 8.3.6. Так и работала без проблем.
Но разработчики выпустили новый релиз, с минимально допустимой версией платформы 8.3.16.1148, и мы установили эту платформу. После этого сама база открылась нормально, пользователи работают. Но попытке внести любые изменения в конфигурации получили ошибку:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом 18: DataHistoryMetadata, Reference18
Определил, что Reference18 - это справочник Валюты. Добавил в него реквизит, и изменил режим совместимости на 8.3.10 - при обновлении ошибка осталась. Поперебирал другие режимы совместимости - все аналогично, ошибка остается.
Напишите пожалуйста, какие другие критерии были в вашей ситуации: тип SQL сервера, какой режим совместимости конфигурации был изначально до изменения на 8.3.10, на какой версии платформы выполняли все действия?
Я думаю вы мое сообщение о том что мне помогло восприняли буквально :)
Оно помогло только если оставаться на этом режиме совместимости 8.3.10 в свойствах конфигурации, если снимать режим совместимости ошибка возвращается.
Характерно вот что, ничего не предпринималось более, разработка идет своим ходом, эти объекты ТОЧНО никто не дорабатывал, но с недавнего времени при ПОЛНОЙ реструктуризации из ТИИ стал ругаться уже на 3 несоответствия, "Имена таблиц с кодом 18: DataHistoryVersions, Reference18 " эта ошибка полностью исчезла... При чем если снимать режим совместимости этой ошибки так же нет, остались три следующих....
Пока сидим на режиме совместимости 8.3.10 благо это позволяет вести доработку. Полная реструктуризация из ТИИ дает эту ошибку все равно даже в режиме совместимости но разработке не мешает. Выгрузка в ДТ загрузка обратно проходит штатно, но ошибку не снимает.
Для нашей базы режим совместимости думаю еще долго был бы подходящим решением. Но так как текущий режим совместимости и так 8.3.6, ниже спускаться уже некуда, хотя я честно говоря попробовал и спуститься и подняться))) - но не помогло.
Другие способы - выгрузка в DT и загрузка, через файловую базу и Postgres, реструктуризация через ТиИ, и так далее - нужного результата так же не дали.
Попробую значит воспользоваться решением, которое предлагает автор этой темы.
Не пробовали в вашем режиме совместимости (8.3.6) выгрузить в DT. Найти/Поставить сервер 1С версии 8.3.6.* и с предприятия той же версии загрузить в чистую базу выгруженный ранее DT. Сделать реструктуризацию через ТИИ. Вернуть обратно последнюю версию сервера и платформы 1С. Перерегистрировать базу на сервере 1С. Зайти в базу и снять режим совместимости ?
Некоторым это помогло, именно в такой последовательности, когда реструктуризированная база на старой платформе подходящей для текущего режима совместимости как будто открывается на только что обновленном сервере 1С с последующим снятием режима совместимости, нам увы нет.
Спасибо за подсказку ее одного варианта действий. Проделал все в указанной последовательности - но увы не помогло.
Вопрос еще ко всем . У меня на данный момент нет стартмани. Может ли кто то продать их или может возможны какие то другие варианты. Если есть возможность - напишите в личку.
На выходных будут опробованы два варианта дополнительно (параллельно буду пробовать оба):
1. Выгрузка в DT (благо это отрабатывает без проблем). Загрузка в postgresql. Реструктуризация там. Если пройдет без ошибок снятие режима совместимости конфигурации. Последующая реструктуризация через ТИИ. Если пройдет без проблем выгрузка в DT и загрузка на SQL в совершенно чистую базу.
2. Если проблема с записями в DBNames и DBSchema то родилась идея за неимением возможности приобрести здешние обработки по (простите мне мой французский) конским ценам...
Собственно идея, создание копии базы на SQL (именно средствами SQL). Регистрация копии на сервере (с отключением регламентных заданий). Вход в конфигуратор копии базы. Сохранение конфигурации в CF. Удаление проблемных объектов из конфигурации с удалением ссылок на эти объекты в других объектах. Сохранение получившейся конфигурации. (на всякий случай перерегистрация базы на сервере 1С). Далее через сравнить объединить накатить сохраненную ранее CF чтобы получить ту же самую базу но с новыми объектами так сказать. Реструктуризация через ТИИ. Если проходит без ошибок то уже дальше средствами SQL копировании из починившейся базы таблиц DBNames и params, а так же config (что-то мне подсказывает что данный способ имеет место жить если все сделать правильно). Надо не забыть что в копии после всех манипуляций необходимо будет зайти и через получение структуры хранения узнать новые имена наших объектов, чтобы потом их переименовать в старой базе. (если что копия у нас будет так как мы ее делали чтобы развернуть рядом вторую базу).
1) postgresql - результат полностью нулевой. собственно потеря времени и только.
2) не хватило места развернуться :) пока откладывается... База несколько сотен гигов а место на серваке не резиновое :( не удалось одновременно несколько испытаний провести.
Второй вариант полностью жизнеспособен. Собственно нужно только время.
Делается копия базы (я делал две). На одной из копий, условно назовем ее 2 следующие действия.
(обязательно сделать выгрузку CF в файл к которой мы должны вернуться)
1. Удаление объектов на которые ругается 1С. У меня это справочники и один из них договоры контрагентов (гемор тот еще). Везде где есть реквизит договор контрагента переделывал на строку 10. И так удалил все справочники. Обновление прошло без проблем.
2. Не знаю есть ли смысл или нет но на всякий случай я это сделал. Удаление с сервера 1С базы (скульную не трогаем). Остановка сервера 1С. Очистка всех кешей и данных, а так же папки которая относится к этой базе в каталоге регистрации сервера 1С. Запуск сервера 1С. Регистрация базы.
3. Реструктуризация через ТИИ.
4. повторил п.2
5. Сравнение объединение с ранее выгруженным CF. Обновляемся. Все хорошо.
6. ТИИ - реструктуризация. Ошибок нет.
7. Заходим в 1С базы 2, смотрим какие имена получили объекты, у меня например вместо ранее "Reference21" объект стал именоваться "Reference21NG" так же запоминаем какие имена получились у других справочников.
8. Копирование на SQL из базы 2 в базу 1 следующих таблиц: [Config] [Configsave] [Params] [DBSchema]
9. Переименование на SQL таблиц в новые имена.
10. Повторил п.2
11. Захожу в базу 1. Делаю ТИИ-Реструктуризация. Профит.
12. На всякий случай выгрузка в DT, загрузка в новую чистую базу на SQL. ТИИ - Реструктуризация. Профит.
13. Снял режим совместимости. Все ок.
Долго нуторно. нужны ресурсы сервера. но способ действенный.
PS Первый раз пробовал но не в точности сделал все как описал выше. В результате при объединении с CF объекты получили то же самое наименование что и было ранее в результате ошибка оставалась :) ЧТо именно из пунктов выше помогло сказать точно не могу, но результат меня порадовал :)
(60)
8. Копирование на SQL из базы 2 в б
Скрин новых имен баз. Странно то что объекты не продолжили нумерацию, а получили буквенные окончания.
Вы были правы насчет NG, после очередной полной реструктуризации имена таблиц изменились и нумерация продолжилась... загадка... Но тем не менее с объектами все в порядке. Уже и посоздавал элементы и помечал на удаление, выбирал в других документах все вроде бы ок на первый взгляд.
В выходные буду на боевой проводить подобный эксперимент.
Проверил вроде все ок.
Добавление реквизитов ВООБЩЕ никак не сказывалось, что только не делал. И к ним реквизиты добавлял разные. и строки и булево, и ссылки на другие справочники/документы/перечисления, объект имел прежнее наименование хоть ты тресни.... И создавал новые справочники и в них пихал реквизиты на проблемные справочники, и перекрестное создание реквизитов делали. Тупость в том что обновление проходило без проблем. А вот ТИИ - Реструктуризация падала с ошибкой.
Смена платформы так же не давала никаких результатов (пробовали поочередно откатываться до 8.3.10.*, сейчас 8.3.16.*), жили долгое время в режиме совместимости конфигурации 8.3.10
В любом случае это не рабочая база. может что-то выстрелит. Это я делал на копиях :) ибо в боевой в течении недели такие действия провести в принципе невозможно.
(66)
Мне больше не понятна следующая картина и ответа дать никто не смог.
Дело в том что пока база находилась в режиме совместимости 8.3.10 я облазил на SQL базу вдоль и попере, таблиц начинающихся на DataHistory* вообще не было !!! Почему при ТИИ платформа ругалась на эти таблицы. Сейчас эти тпблицы появились после снятия совместимости. и теперь их хоть видно :) но почему в режиме совместимости при ТИИ платформа ругалась на эти таблицы - мне не понятно до сих пор.
Полностью жизнеспособный вариант, вылечено несколько огромных баз. Но для моего конкретного случая, когда ни ТИИ, ни выгрузки в DT, ни загрузки в другие варианты баз, ни добавления реквизитов не давали ровно никакого результата. А купить обработки здесь возможности тупо нет. И да у меня полностью не типовая конфигурация на базе УТ 10.2 которая переписана вдоль и поперек, поэтому накатить обновление как я видел где то советы так же отметалось.
Перезапускать ничего не надо, ни сервер 1С, ни SQL. Чистить кэши и прочее тоже ни к чему.
1. Делаете копию средствами SQL (это прям всегда пред телодвижениями). Сохраняем из под конфигуратора CF - это то к чему нам надо будет вернуться. (нужная так сказать структура).
2. Поднимаете копию базы средствами SQL. Эта база - мученик, она в дальнейшем ни для чего не пригодится от слова совсем. Так как будет изувечена.
3. В каждом конкретном случае индивидуальный подход но суть думаю будет ясна. В моем случае мне мешали справочники, один из которых "Договоры контрагентов" которым база пропитана вдоль и поперек сверху до низу. И так в копии создаются новые справочники вида "Справочник_ДоговорыКонтрагентов", "Справочник_ДругойПоломанныйСправочник" ну или например "Документ_ПоломанныйДокумент" собственно суть понятна, после нижнего прочерка точное наименование поломанного объекта (тупо для того чтобы эти объекты получили новый номер). Обновление и принятие новых данных.
4. Так как база несколько сотен гигов, а ждать напрасно времени нет, были написаны скрипты которые зачистили самые большие таблицы в копии базы (мученике), чтобы не тратить напрасно время на реструктуризацию. Собственно немного покопавшись в инете можно самому написать обработку которая сгенерит SQL скрипт который зачистит объекты больше какого то объема... В результате база мученик стала весить около 10 гигов что меня вполне устраивало. Можно было совсем в ноль ужать но некоторые данные были нужны при старте 1С чтобы не переписывать код при начале работы системы (мне нужны были полностью идентичные данные таблицы config).
5. Удаление в базе поломанных объектов, все что ссылалось на них в реквизитах (и прочее) было заменено на строку-10 (по умолчанию). Можно руками, можно через выгрузку конфигурации в файлы и обработкой опять же пробежаться по файлам (но не везде это проходит как и в моем случае, пришлось руками). Обновление конфигуратора.
6. Переименование объектов которые были созданы для поломанных, то есть "Справочник_ДоговорыКонтрагентов" в "ДоговорыКонтрагентов" и так далее для всех поломанных объектов. Обновление конфигурации.
7. ТИИ - реструктуризация. почти мухой.
8. Сравнение объединение конфигурации с ранее выгруженным CF, принимаем изменения. В результате у вас будет не создание справочников (так как поломанные объекты мы удаляли) а обновление имеющихся (так как мы создавали для них новые справочники которые получили новую нумерацию). Обновляем конфигурацию.
9. ТИИ - реструктуризация, почти мухой.
10. Запускаем 1С и смотрим какие имена получили новые объекты. ВНИМАНИЕ! Помимо того что будут переименовываться сами таблицы, относящиеся к объектам, так же надо будет переименовать реквизиты внутри них если они имели нумерацию как у меня. ВНИМАНИЕ! Помимо того что вы переименуете таблицу которая относится к этому справочнику так же надо будет переименовать Таблицу (если она будет) которая относится к предопределенным данным (как в моем случае). На самом деле, опять же можно написать обработку которая сгенерит вам скрипт переименования объектов (ну или ручками). Обработка до нельзя простая, по COM подключаемся к живой базе получаем структуру хранения нужных объектов, потом в мученике так же получаем структуру хранения нужных объектов, дальше дело техники...
11. После переименования нужных объектов в ПРАВИЛЬНОЙ базе, необходимо из базы МУЧЕНИКА скопировать таблицы [Config] [Configsave] [Params] [DBSchema] в нужную базу.
Если все было сделано правильно заходим в 1С нужной базы проверяем работоспособность объектов которые считались поломанными. Радуемся. Далее так как у меня был режим совместимости 8.3.10 я снял режим совместимости. ТИИ - Реструктуризация (все ок нареканий нет платформа не жалуется), далее на всякий случай проверка логики. Все чисто. Боевые базы работают второй день. полет более чем нормальный... Никто не жалуется.
Если кто-то скажет что это неправильно и так делать нельзя, скажите чем мой способ, хоть он и более долгий, отличается от способа вмешательства напрямую в DBSchema и прочите таблицы и там переименования/перенумерации объектов (но за деньги) ? Моим способом реанимировано несколько огромных баз и все они работают без проблем на текущий момент.
На данный способ натолкнула идея прямого вмешательства в таблицы, описанного здесь, и посетила идея что если способа вмешаться напрямую нет, можно заменить эти значения из другого источника, ну а как получить нужный источник описано выше.
Спасибо за внимание.
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом 18: Const18, Reference18
Имена таблиц с кодом 20: Const20, Reference20
Имена таблиц с кодом 22: AccumRg22, Reference22
Имена таблиц с кодом 27: AccumRgT27, Reference27
Имена таблиц с кодом 28: AccumRgOpt28, Reference28
Имена таблиц с кодом 29: ExtensionsInfoNGS, Reference29
Имена таблиц с кодом 30: ExtensionsRestruct, Reference30
Имена таблиц с кодом 31: ExtensionsRestructNGS, Reference31
Имена таблиц с кодом 34: DataHistoryQueue0, Reference34
Что было попробовано из бесплатных вариантов:
1) Тестирование и исправление c флажком Реструктуризация.
2) Выгрузка и загрузка в dt-файл.
3) Выгрузка в dt-файл, установка Postgre, загрузка dt-файла в Postgree, выгрузка его из Postgree и загрузка на SQL
4) Выгрузка конфигурации в XML-файлы и ручное изменение uuid у проблемных объектов.
Ничего из этого не помогло. Пришлось покупать вышеуказанную обработку.
Далее я приведу четкий алгоритм использования этой обработки, который сработал на нашей базе.
В каждой проблемной паре выбираем один из объектов, с которым будем работать. В данном случае “жертвами” стали следующие объекты:
1) Const18, Reference18. “Жертва” - Const18 - Константа.КассаПеремещение
2) Const20, Reference20. “Жертва” - Const20 - Константа.КассаЗарплата
3) AccumRg22, Reference22. “Жертва” - AccumRg22 - РегистрНакопления.ПеремещениеДС (Основная)
4) AccumRgT27, Reference27. “Жертва” - AccumRgT27 - РегистрНакопления.ПеремещениеДС (Итоги)
5) AccumRgOpt28, Reference28. “Жертва” - AccumRgOpt28 - РегистрНакопления.ПеремещениеДС (НастройкиХраненияИтоговРегистраНакопления)
6) ExtensionsInfoNGS, Reference29. “Жертва” - Reference29 - Справочник.ЕдиницыИзмерения
7) ExtensionsRestruct, Reference30. “Жертва” - Reference30 - Справочник.ЗначенияСвойствОбъектов
8) ExtensionsRestructNGS, Reference31. “Жертва” - Reference31 - Справочник.Календари
9) DataHistoryQueue0, Reference34. “Жертва” - Reference34 - Справочник.КлассификаторЕдиницИзмерения
Запускаем обработку.
Указываем параметры подключения к SQL (заполняем все поля, кроме поля “Имя копии базы”).
В поля “Файл схемы” и “Файл имен” вводим пути для будущих файлов. Например, “C:\TEMP\bdschema.bin” и “C:\TEMP\DBNames.txt” соответственно. Эти файлы будут созданы позже самой обработкой.
Для начала распознаем схему базы данных. Вся схема -> Список объектов -> Распознать схему базы. Распознанную схему выгружаем в файл через кнопку “Выгрузить схему из списка в файл”. Таблицу имен выгружаем через кнопку “Загрузить из БД в файл” (эта кнопка находится вверху обработки напротив пути, где мы указывали путь к файлу имен).
Полученные файлы “bdschema.bin” и “DBNames.txt” открываем в Notepad++.
Берем первую проблемную пару. Жертву из первой пары (Const18) ищем в файле “DBNames.txt”. Найденная строка выглядит так: {eee363bd-e278-428e-a7c3-fb6f80415746,"Const",18}. Вырезаем эту строку и вставляем ее в конец файла. При этом меняем “18” на новый номер, который на +1 больше, чем номер в предпоследней строке. В моем случае строка стала выглядеть так: {eee363bd-e278-428e-a7c3-fb6f80415746,"Const",11768}.
В самом начале файла “DBNames.txt” в первой строке указан максимальный номер (раньше там был 11767), но максимальный номер у нас уже 11768, поэтому первую строку тоже изменяем. Теперь она выглядит так: {11768,
С файлом “DBNames.txt” закончили, сохраняем его.
Переходим к файлу схемы “bdschema.bin”. В нем нужно найти все упоминания нашей жертвы. Я пользовался командой Поиск -> Найти все в текущем документе. Ищем “Const18”. Результат поиска 1 строка, которая выглядит так: {"Const18","N",18,"",
В этой строке меняем “18” на “11768”. Получаем такую строку: {"Const11768","N",11768,"",
Если результат поиска – несколько строк, то меняем “18” на “11768” в каждой из них. Сохраняем файл.
Идем в обработку. Теперь нам нужно загрузить наши новые файлы обратно. Для файла схемы заходим в Вся схема -> Текст -> Прочитать схему из файла. Для файла имен: Имена -> Прочитать DBNames из файла.
После этого вверху обработки жмем поочередно 2 кнопки “Выгрузить в БД”.
Закрываем 1С, идем в “SQL Server Management Studio”, там находим нашу базу и создаем к ней запрос для переименования таблиц: EXEC sp_rename _Const18, _Const11768. Выполняем запрос.
Следующим шагом обязательно нужно удалить базу из Кластера 1С и загрузить ее туда обратно. Для этого заходим в “Администрирование серверов 1С”, находим нашу базу в кластере и удаляем ее с флажком “Оставить без изменений”. База удалена и можно заново добавить ее в кластер с прежними настройками.
После этого можно запускать 1С. Ошибка с нашей первой парой (Const18, Reference18) пропала.
Все то же самое нужно проделать с каждой проблемной парой. При этом можно сразу выполнить все замены в файлах для всех строк ошибок за 1 раз, а потом поочередно переименовать все таблицы.
В итоге конец файла “DBNames.txt” у меня выглядел следующим образом:
{eee363bd-e278-428e-a7c3-fb6f80415746,"Const",11768},
{bc56b272-4023-48e5-a4ac-755b878d2f1d,"Const",11769},
{7e27c633-69b2-4ac0-b7d5-0257b989a4c5,"AccumRg",11770},
{7e27c633-69b2-4ac0-b7d5-0257b989a4c5,"AccumRgT",11771},
{7e27c633-69b2-4ac0-b7d5-0257b989a4c5,"AccumRgOpt",11772},
{d37c9a18-64d9-4df1-ab12-f564f16eb59c,"Reference",11773},
{02eb864a-c046-4e26-ab09-d57934e0aba2,"Reference",11774},
{1c09bf33-9b54-4bfd-bc92-e7324025fab0,"Reference",11775},
{efad9316-ebd0-45d1-81d0-4717759dea54,"Reference",11776}
А запросы в SQL выглядели так:
EXEC sp_rename _Const18, _Const11768
EXEC sp_rename _Const20, _Const11769
EXEC sp_rename _AccumRg22, _AccumRg11770
EXEC sp_rename _AccumRgT27, _AccumRgT11771
EXEC sp_rename _AccumRgOpt28, _AccumRgOpt11772
EXEC sp_rename _Reference29, _Reference11773
EXEC sp_rename _Reference30, _Reference11774
EXEC sp_rename _Reference31, _Reference11775
EXEC sp_rename _Reference34, _Reference11776
Любое отклонение от указанного алгоритма у меня приводило к фатальной ошибке потока при открытии базы 1С, так что пробуем на копии, а потом уже на живой базе.
Если остался интерес и "битая" база - попробуйте.
Да, у вас проблемный объект - перечисление, а не справочник. Но попробуйте к справочнику добавить.
При реструктуризации конфигуратор создает новую таблицу (с новым номером), копирует все записи в соответствии с полями, а старую таблицу удаляет, схему корректирует в соответствии с новым номером.
Таким образом дублирование исчезает.
Поэтому от добавления значения для перечисления добавится лишь запись в таблице, а создание новой таблицы не произойдет.
Исправил схему, Исправил таблицу имен, переименовал таблицы.
Пересоздал базу. (удалил в 1с, создал на освободившейся базе SQL)
Проверяю исправления в базе, таблица есть и в схеме и в таблице имен
"Вся схема - Текст - Загрузить из SQL":
{"ByOrder",1,
{2,"EnumOrder","ID"},0,0,0}
},1,"R",
{0},
{0},"",0,0},
{"Enum36589","N",36589,"",
{2,
{"ID",0,
{1,
{"R",0,0,"Enum36589",2}
},"",0},
{"EnumOrder",0,
{1,
Кнопка "Загрузить из БД в файл".
Смотрю файл:
{9d17dfca-337e-44a6-b1f2-b7bf9ca1f9ee,"Enum",36587},
{050975fa-772c-4ce0-98d4-04289d6622b0,"Enum",36588},
{ced20a30-7d1b-431b-8276-e247307df415,"Enum",36589}
Т.е. Схема и Таблица имен в базу загрузилась.
Переименовал таблицы базы. Проверил, новые таблицы есть.
При ТиИ реструктуризация, выскочила:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Тип поля CAST(Document251.VT34516.Fld34520 AS REF(Enum377)) AS Fld34520 несовместим с типом поля Fld34520
Снял с поддержки, поменял тип этого поля. Хотя не понятно, что там не так.
При сохранении конфигурации в базу:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
В схеме базы данных отсутствует таблица "Enum36590".
Это следующий свободный номер в Таблице имен. Кто решил его занять?
В схеме и в таблице имен этого номера нет.
Тупик.
- обновиться на платформе ниже 8.3.15 (точно прокатит)
- или пробовать самую свежую платформу (не факт)
Переименовал таблицы базы. Проверил, новые таблицы есть.
При ТиИ реструктуризация, выскочила:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Тип поля CAST(Document251.VT34516.Fld34520 AS REF(Enum377)) AS Fld34520 несовместим с типом поля Fld34520
Спустя месяц вернулся к проблеме.
Понял. В моем случае еще и сбилась схема соответствия полей.
А релиз платформы 8.3.16.1148 проблему не решил (ТИИ)
Возможно, вы переименовали основную таблицу объекта в sql, но не учли ссылки на этот объект в других местах (например, в ТЧ у какого-то документа).
Именно поэтому рекомендую выбрать "жертву" ту, у кого нет табличных частей (и на кого нет нескольких ссылок в DBSchema).
Дайте текст ошибки вида:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом 1: xxx, yyy
Ошибка SDBL:
Тип поля CAST(Document251.VT34516.Fld34520 AS REF(Enum377)) AS Fld34520 несовместим с типом поля Fld34520
(36)
Дмитрий, конечно это табличная часть, конечно она принадлежит документу.
Я понял, что табличные, да и все реквизиты, тоже имеют нумерацию, а у них имеется такое же сопоставление.
Оно также записано в схеме, и если сопоставление испорчено, то при проверке может не совпасть тип.
Хорошо, что то что в них записано при Реструктуризации не проверяется, проверяется только тип.
В этом и ошибка.
Теперь я это понял, и эту проблему уже исправлю. НО
Тогда я ручками это все проделывал (переименования и прочее) повторять ручками уже не хочу. Сейчас пишу обработку для этих целей.
Еще одна база проявила себя, буду автоматизировать исправление.
по причине:
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом 1: CKinds1, CKindsDN605
Имена таблиц с кодом 2: CKinds2, CKindsDN639
Для исправления проблемы вы можете обратиться в службу технической поддержки.
Реструктуризацию провести не смог, вываливается. База большая, около 500Г. Возможно из-за этого.
CKinds - это план видов расчета. Какой именно я не стал определять (можете поиграться со структурой, кому интересно). Я просто добавил КАЖДОМУ из плана видов расчета (у меня их всего 6) новый реквизит и ошибка исчезла!!! Затем Все эти реквизиты убрал за ненадобностью.
Релиз 1С:Предприятие 8.3 (8.3.15.1489) Конфигурация УТП (Украина)
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом 333: CKinds333, CKindsDN863
Имена таблиц с кодом 641: CKinds641, CKindsDN671
вот таким кодом я получил соответствие таблиц SQL и метаданных
СтруктураХраненияБазыДанных = ПолучитьСтруктуруХраненияБазыДанных();
сч=1;
Для Каждого ЭлементСтруктуры Из СтруктураХраненияБазыДанных Цикл
новстр = объект.ТабличнаяЧасть1.Добавить();
новстр.реквизит1 = ЭлементСтруктуры.ИмяТаблицыХранения;
новстр.реквизит2 = ЭлементСтруктуры.Метаданные;
КонецЦикла;
КонецПроцедуры
узнал что в моем случае это были
Планывидовхаракетристик.Начисления
Планывидовхаракетристик.Удержания
добавил по реквизиту.. и обновление прошло успешно.
2) также помогло.
параллельно с этим выгружался в файловую базу.. произвел ТИИ- реструктуризацию.. в моем случае тоже помогло 8.3.16
еще раз всем спасибо.
1С Линия консультации Вчера, 13:28
Кому: вам
Здравствуйте!
Присылайте базу в ремонт. Самостоятельно не лечится.
Вам предоставлен ресурс для передачи службе технической поддержки дополнительных файлов ,
в рамках вашего обращения (#HL-106678) , просьба загружать данные только относящиеся к этому обращению.
Никаких замечаний по несоответствию поля уже не было. Видимо ручками что-то испортил.
А с обработкой прошло все гладко. Даже не сбрасывал кэш, не производил "тестирование и исправление" базы.
Если есть где развернуть 1с сервер с предыдущей платформой, переключаем на него базу, опять же добавляем реквизиты в проблемные объекты и обновляемся, потом на новой платформе проблем нет, это если по какой то причине не поможет добавление реквизитов на новой платформе.
Платформа 8.3.16.1063
Ошибка SDBL: Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных. Имена таблиц с кодом 18: ExtensionsInfoNGS, Reference18 Имена таблиц с кодом 19: ExtensionsRestruct, Reference19 Имена таблиц с кодом 20: ExtensionsRestructNGS, Reference20 Имена таблиц с кодом 24: DataHistoryMetadata, Reference24
Это таблицы справочников банк, банковские счета, виды контактной информации и адресные сокращения
При реструктуризации те же ошибки
Пробовал добавлять реквизиты, загружать в чистую базу, в файловом и клиент серверном режиме ничего не помогало
Решение с удалением таблиц и загрузкой из CF помогло, но не удалось вернуть данные
Помогло следующее:
Создал узел для базы (РИБ), потом отвязал эту базу от основной и реструктуризация прошла успешно. Можно работать в этой базе только нужно заново активировать пользователей
Или я чего - то делаю не так?
Я делаю:
1) Открываю проблемный документ
2) Перехожу в "Данные"
3) Добавляю любой реквизит
4) Сохраняю конфу БД, все верно?
В общем не работает этот метод. Платформа 8.3.18.1208, конфа файловая.
Поправьте если чего не так сделал...
P.S. И вообще, немного непонятно, почему это должно помочь - ведь идентификатор таблицы документа при добавлении реквизита не меняется!
В данном случае помогла простая штатная процедура.
Пердистория:
Пользовали платформу 8.3.18.1334 в режиме клиент-сервер. У нее есть глюк впадать в коматозное состояние с загрузкой процессора под 80-90% и потерей сетевых подключений. В результате чего возникли проблемы с добляжем ссылок.
Теперь о главном. Тестирование и исправление, загрузка-выгрузка не спасли отца русской демократии.
Создвл пустую базу из шаблона последнего обновления БП в файловом варианте.
В другую файловую базу загрузил выгрузку из битой БД.
Настроил штатными средствами синхронизацию БП->БП
Сначала перенес справочники, затем перенес документы и выполнил закрытие месяца от царя гороха до текущего.
Выгрузил БД и загрузил в SQL
Ошибка ушла.
Закрытие месяца от времен царя гороха.
Чтоб цифры "поплыли"? На реальных базах многолетних такое не прокатит. Я уж не говорю что базы коллег очень часто в файловые не помещаются, т.к. занимают сотни Гб.
ЗЫ
Вообще, закрытие месяца он сам предложит от начала и до месяца по выбору....
// получить DBSchema
SEL ECT CAST(serializeddata as xml) as DBSchema FROM DBSchema
// получить DBNames
SELECT CAST(DECOMPRESS(0x1F8B0800000000000400 + BinaryData) as xml) as DBNames FR OM Params WH ERE FileName = 'DBNames'
Почему то лишние пробелы вставляются в текст, не знаю что тут с комментариями
При обновлении БП словил ошибку (смю 1 файл) Из названия таблиц понятно что проблема в константах и регламентных заданиях, далее воспользовался советом, добавил реквизит к Документу Авансовый отчет (скр 2), и обновление прошло.
1С:Предприятие 8.3 (8.3.25.1501)
Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.167.36)
Рейтинг: 250
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1126277
Создание 23.09.19 18:20
Обновление 24.10.20 11:37
Просмотры 43446
Загрузки 0
Рейтинг
55
Комментарии 93
Код открыт Да
Рубрики Корректировка данных
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
