Исправление ошибки "Для одного ссылочного кода существует более одной таблицы в базе данных"

24.10.20

Задачи пользователя - Корректировка данных

Описана методика исправления ошибки путем внесения изменений в sql-таблицы.

Отказ от ответственности: вы все здесь взрослые и делаете всё на свой страх и риск. Да, и ещё: лицензионное соглашение не разрешает вам это делать, поэтому данное описание дано для образовательных целей.

После перехода с 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 в файл и обратно.

А я опишу методику лечения баз:

  1. рекомендуется использовать Notepad++ или аналог. В отдельном файле открыть текст ошибки из конфигуратора.
  2. запустить обработку, получить DBSchema (схема - список объектов - распознать схему) и DBNames (вверху "загрузить из БД в файл"), выгрузить обе структуры в файлы, указав вверху пути и нажав на кнопки "выгрузить схему из списка в файл" и "загрузить из БД в файл". Открыть файлы в Notepad++, выставить синтаксис "С/С#" (или иной - для удобства сворачивания групп). Должно получиться примерно следующее (слева DBNames, справа - DBSchema):
  3. из текста ошибки для каждой пары объектов выбрать "жертву"; проще менять номер у констант или регистров, т.к. на них обычно нет ссылок в реквизитах других объектов. Желательно выбирать в таком качестве "таблицы изменений" вида _ConstChngR2346 или _DocumentChngR3078 не имеющие табличных частей (у нет таблиц вида Document750.VT20237 или _Reference49197_VT3332).
  4. в DBNames находим строку жертвы по номеру объекта, переносим строку в конец файла, меняем номер объекта (+1 к предыдущему)
  5. в файле с текстом ошибки к номеру "жертвы" добавляем "-НовыйНомер"
  6. в DBSchema находим объект, меняем номер объекта (в третьем параметре); ищем все вхождения имени объекта (например Reference3048) - ссылки на этот объект в реквизитах других объектов - выполняем замену например Reference3048 на Reference49189.
  7. в DBNames первый параметр меняем на новый максимальный номер объекта
  8. сохраняем файлы, считываем их обработкой (вся схема - текст - прочитать схему из файла, Имена - Прочитать DBNames из файла), выгружаем из обработки в БД
  9. пишем 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. после выполнения указанных действий также рекомендую удалить-добавить базу в кластере.
    Хотя от представителя 1с на партнерском форуме есть альтернатива - рекомендация перезапускать сервер - в комментариях (7) к данной статье коллега отписался о неэффективности этого метода.

upd 24.01.2020: рекомендую ознакомиться с обработкой из комментария 39.

 

Понравилась статья? Поставь плюс. Рекомендую другие статьи:

Хотите снизить нагрузку на процессор сервера в 2 раза?

Очистка диска от кэша неиспользуемых баз 1С

См. также

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтер Пользователь Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020    32855    106    152    

73

Корректировка данных Системный администратор Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Незаменимая обработка для сопровождения конфигураций: ERP, УТ, КА. Позволяет вычистить многие ошибки в ключах аналитики, в ключевых справочниках конфигурации.

3600 руб.

10.02.2017    110633    663    174    

702

Закрытие периода Корректировка данных Бухгалтер Пользователь Платформа 1С v8.3 Оперативный учет 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Управленческий учет Платные (руб)

Закрытие месяца - важный процесс в современных конфигурациях, таких как УТ 11.4, УТ 11.5, КА 2.4, КА 2.5 ERP 2.4,ERP 2.5, КА 2 Казахстан, УТ 3 Казахстан регламентные операции влияют на расчет себестоимости, и ошибки в данном расчете не дают картины деятельности организации.

4800 руб.

27.10.2021    24003    242    35    

79

Корректировка данных Зарплата Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры бюджетного учреждения 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет НДФЛ Платные (руб)

Обработка исправляет технические ошибки по НДФЛ, взаиморасчетам с сотрудниками в 1С:ЗУП (1С:ЗКГУ) на начало года. Фактически все ошибки, которые проявляются в ведомостях на выплату, расчетных листках, при заполнении ведомостей на выплату и отчетах 6-НДФЛ и т.д. нужно начинать исправлять с начала расчетного года. Это позволит быть уверенными, что после завершения расчетов предыдущего года, начали работать с «чистого листа» без ошибочных остатков.

4800 руб.

06.10.2023    4074    35    18    

44

Корректировка данных Программист Бухгалтер Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет НДС Платные (руб)

Обработка предназначена для корректировки входящего НДС при смене системы налогообложения индивидуального предпринимателя с УСН на ОСНО в 1С:Бухгалтерия предприятия 3.0

4000 руб.

18.07.2024    709    1    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. vladpisklov 23.09.19 19:47 Сейчас в теме
Мне помогло просто выгрузить базу в *.dt из sql, загрузить в Postgres, выгрузить обратно в *.dt и опять загрузить
adhocprog; Vyacheslide; +2 Ответить
5. TMV 14 24.09.19 18:11 Сейчас в теме
(1) кажется и через файловую сработает. Но всё упирается в размер.
2. vladpisklov 23.09.19 19:48 Сейчас в теме
Мне помогло просто выгрузить базу в *.dt из sql, загрузить в Postgres, выгрузить обратно в *.dt и опять загрузить в SQL. Проблемма исчезла
4. Дмитрий74Чел 239 24.09.19 18:11 Сейчас в теме
53. user970589 11 20.02.20 15:08 Сейчас в теме
(2)
помогло просто выгрузить базу в *.dt из sql, загрузить в Postgres, выгрузить обратно в *.dt и опять загрузить в SQL. Проблемма
а если постгри нет? )
3. Alfie83 24.09.19 18:02 Сейчас в теме
Мне помог * платформы на предыдущий релиз, где эта ошибка не возникала. Сделал копии поломанных объектов заново в конфигураторе, стараясь избегать объектов ссылочных типов (мне повезло в паре к справочникам поломаны были несколько регистров сведений и накопления). Скопировал информацию оттуда опять же средствами 1с. Старые объекты удалил. И запустил на свежей платформе с перезапуском сервера 1с. Выгрузка или ТиИ занимает много времени поэтому пришлось так.
6. user1284675 30.09.19 14:51 Сейчас в теме
Что было предпринято и не помогло, на что не стоит тратить время:

- Тестирование и исправление на уровне конфигуратора - результат: долго проверяет и в итоге вываливает ту же самую ошибку без исправления;

- Выгрузка базы в Dt –файл и загрузка его в чистую базу – ошибка не исчезает;

- Выгрузка базы в Dt –файл и загрузка в файловый вариант – ошибка не исчезает;

- Установка Postgre и загрузка данных туда из Dt –файла, снова выгрузка в Dt –файл и загрузка в базу на SQL север;

- Тестирование встроенным проверщиком утилитой chdbfl - тоже ничего не нашло и ошибку не исправило.

При всех этих вариантах структура базы переносилась с ошибкой и ничего не менялось.

Что помогло

купили обработку:
Однако, в ней нет инструкции, что и как, по чату с разработчиком удалось восстановить целостность базы данных. Обработка помогла, база восстановлена. Рекомендую провести восстановление на копии базы, А затем, когда уже будут готовые текстовые файлы с исправленным содержимым для DBNames и СхемаБазы - просто обновить эти таблицы из этих файлов и после сделать запрос: sp_rename _ReferenceХХXX, _ReferenceYYYY - где ХХХХ номер с задвоением таблиц, YYYY - следующий свободный порядковый номер в таблице имен.
Если ошибок несколько, то по каждой надо отдельно вносить корректировки.
Вносить корректировки лучше через автопоиск и автозамену, т.к. малейшие неточности приведут к тому, что при открытии базы получите надпись "Ошибка открытия потока" и восстановить базу можно будет только с бэкапа SQL

За тем, как именно это делается обращайтесь к разработчику или пишите в личку, вышлю свою инструкцию что и как делал.
user784245; ybatiaev; +2 Ответить
25. Mekadote 3 20.12.19 15:20 Сейчас в теме
(6)
Зафиксировано исключение из подпункта 1.
ТиИ помогло, НО оно должно быть провоедено в файловом формате и на новой платформе (в моем случае на 8.3.15.1778)
потом нужно на файловой же завершить обновление и только потом через dt в клиент-серверный вариант
ЗЫ был переход УПП 1.3.128.2 -> 1.3.129.1 была только 1 конфликтующая пара (документ (осн. табл) и регистр сведений (также осн. табл)) база 0,9 Gb в файловом формате
7. k9260130000 27 21.10.19 01:18 Сейчас в теме
Благодарю помогло. Но таки поправь в статье - "P.s. после выполнения указанных действий также рекомендую удалить-добавить базу в кластере, или перезапустить службу. " Заменить на п.10 Обязательно удалить/добавить ИБ в кластере .Если просто рестартовать сервер ошибки будут - проверил ((
8. user949348 19.11.19 12:16 Сейчас в теме
Ну и еще "добавить реквизит к объекту и обновить БД" (этот пункт не пробовал, напишите в комментариях - вдруг это самый простой метод) - похоже что да, помогло на версии 8.3.16.1030
adhocprog; Resha; freeek; avant2004; alena_igorevna; Дмитрий74Чел; +6 Ответить
9. alena_igorevna 33 21.11.19 14:30 Сейчас в теме
(8)"добавить реквизит к объекту и обновить БД" если несколько объектов то нужно к каждому добавить. Помогло на платформе 1С:Предприятие 8.3 (8.3.15.1747)
10. user687083_vinsla 24.11.19 09:50 Сейчас в теме
(8) у меня было 40! задублированных ссылочных кодов таблиц. Мне помогла выгрузка данных для перехода в сервис из битой базы и загрузка их в чистую базу. Платформа 8.3.16.1030
Ujine1313; avant2004; +2 Ответить
12. Дмитрий74Чел 239 25.11.19 10:50 Сейчас в теме
(10) а где эти пункты меню?
14. user687083_vinsla 25.11.19 11:39 Сейчас в теме
(12) В режиме предприятия: Администрирование - Сервис - Выгрузить данные для перехода в сервис. Если команда не видна - в верхнем углу шестеренка - Настройка действий. Там же и команда загрузки данных из сервиса. (11) База небольшая. Для больших баз конечно, наверное, проще возиться с добавлением атрибутов или действовать по плану (6), тут каждый выбирает что ему подходит
Mastekor; +1 Ответить
46. Mastekor 03.02.20 16:21 Сейчас в теме
54. user970589 11 20.02.20 15:21 Сейчас в теме
(14)
Выгрузить данные для перехода в сервис

полагаю, что вариант Управление производственным предприятием, редакция 1.3 (1.3.120.1) тут не пройдет ( ибо не 8.3
62. Ujine1313 10 12.03.20 16:34 Сейчас в теме
(10)Спасибо за совет. не стал заморачиваться с иправлением ошибки - выгрузил то же все в сервис и потом загрузил в чистую базу - помогло.
11. user949348 25.11.19 08:16 Сейчас в теме
размер базы какой у вас?
13. Дмитрий74Чел 239 25.11.19 11:30 Сейчас в теме
15. user949348 25.11.19 14:08 Сейчас в теме
ну тогда можно и dt выгружать пробовать, у нас так не получится, поэтому сразу решили реквизитами пробовать исправлять
16. user646807_kazako.a911 14 25.11.19 17:39 Сейчас в теме
На мой взгляд не совсем корректное решение. Правильное: https://infostart.ru/public/1147114/
17. Риник 15 27.11.19 17:41 Сейчас в теме
(16) ахаха ты просто скопировал коммент автора со своего поста и заменил ссылку? Обиделся шоль?)
Дмитрий74Чел; +1 Ответить
18. Дмитрий74Чел 239 28.11.19 17:27 Сейчас в теме
(17) Очевидно да, он обиделся.
19. Дмитрий74Чел 239 28.11.19 17:31 Сейчас в теме
(16) Ответ на твой вопрос "Чем же решение Дмитрий74Чел корректней (правильней) чем решение user646807_kazako.a911? "

В решении от user646807_kazako.a911 предложено поменять UUID на произвольный. Не на правильный (которого -то и нет, т.к. проблема не в UUID), а на какой-то там любой.
Тем более сомнительна рекомендация "В файле "ConfigDumpInfo" UUID объекта можно не менять.". Т.е. в одном месте конфигурации у документа будет один идентификатор, а в другом - другой. На мой взгляд так получаем битую конфигурацию. То, что метод сработал на одной базе скорее всего является следствием лишь того, что в ней указанный документ не использовался.

В решении Дмитрий74Чел приведены несколько вариантов, как сложных (с заменой номеров объектов), так и простых и 100% безопасных (временное добавление объекту реквизита).
20. ZloyGenii 02.12.19 15:35 Сейчас в теме
Может кто из гуру подскажет как быть в такой ситуации ?
Если в посте выше ошибка конкретно указывает на действительно существующие объекты где номер одинаковый, то у нас например вообще не понятно что именно не нравится конфигуратору и платформе...

"В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.

Имена таблиц с кодом 18: DataHistoryVersions, Reference18
Имена таблиц с кодом 19: DataHistoryLatestVersions, Reference19
Имена таблиц с кодом 20: DataHistoryMetadata, Reference20
Имена таблиц с кодом 21: DataHistorySettings, Reference21
Для исправления проблемы вы можете обратиться в службу технической поддержки."

Я не наблюдаю в первых ссылках на всякие инструменты хранения истории хоть какой то нумерации, к тому же инструментарий хранения историй полностью выключен... 1С пока что работает под пользователем.

Добавление реквизитов к выше упомянутым справочникам вообще в принципе ничего не дает... Натолкните куда копать и как решать ? Платформа по сути ругается на все то что связано с инструментом истории данных...

направьте куда копать....
21. ZloyGenii 03.12.19 17:00 Сейчас в теме
(20)

В моем случае помогло ПОМИМО добавки временных реквизитов к данным объектам еще смена режима совместимости в конфигураторе на "Версия 8.3.10"

Может кому то поможет... После данных манипуляций конфигурация обновилась без ошибок.
23. Дмитрий74Чел 239 09.12.19 11:46 Сейчас в теме
(21) полагаю, ключевое изменение здесь именно понижение версии совместимости. Т.е. по-сути вы просто отключили механизм проверки встроенный в 8.3.15
56. Oleg_Anat 10.03.20 10:55 Сейчас в теме
(21)
Руслан, у меня похожая ситуация, попытался проделать так же как и вы, но не получилось.

Конфигурация "Рарус:Альфа-авто v.5", использовалась на платформе 8.3.13. В свойствах у нее установлен родной (от разработчиков) режим совместимости 8.3.6. Так и работала без проблем.
Но разработчики выпустили новый релиз, с минимально допустимой версией платформы 8.3.16.1148, и мы установили эту платформу. После этого сама база открылась нормально, пользователи работают. Но попытке внести любые изменения в конфигурации получили ошибку:

Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.
Имена таблиц с кодом 18: DataHistoryMetadata, Reference18

Определил, что Reference18 - это справочник Валюты. Добавил в него реквизит, и изменил режим совместимости на 8.3.10 - при обновлении ошибка осталась. Поперебирал другие режимы совместимости - все аналогично, ошибка остается.

Напишите пожалуйста, какие другие критерии были в вашей ситуации: тип SQL сервера, какой режим совместимости конфигурации был изначально до изменения на 8.3.10, на какой версии платформы выполняли все действия?
57. ZloyGenii 10.03.20 14:21 Сейчас в теме
(56)

Я думаю вы мое сообщение о том что мне помогло восприняли буквально :)
Оно помогло только если оставаться на этом режиме совместимости 8.3.10 в свойствах конфигурации, если снимать режим совместимости ошибка возвращается.

Характерно вот что, ничего не предпринималось более, разработка идет своим ходом, эти объекты ТОЧНО никто не дорабатывал, но с недавнего времени при ПОЛНОЙ реструктуризации из ТИИ стал ругаться уже на 3 несоответствия, "Имена таблиц с кодом 18: DataHistoryVersions, Reference18 " эта ошибка полностью исчезла... При чем если снимать режим совместимости этой ошибки так же нет, остались три следующих....

Пока сидим на режиме совместимости 8.3.10 благо это позволяет вести доработку. Полная реструктуризация из ТИИ дает эту ошибку все равно даже в режиме совместимости но разработке не мешает. Выгрузка в ДТ загрузка обратно проходит штатно, но ошибку не снимает.
58. Oleg_Anat 11.03.20 05:59 Сейчас в теме
(57)

Для нашей базы режим совместимости думаю еще долго был бы подходящим решением. Но так как текущий режим совместимости и так 8.3.6, ниже спускаться уже некуда, хотя я честно говоря попробовал и спуститься и подняться))) - но не помогло.

Другие способы - выгрузка в DT и загрузка, через файловую базу и Postgres, реструктуризация через ТиИ, и так далее - нужного результата так же не дали.

Попробую значит воспользоваться решением, которое предлагает автор этой темы.
59. ZloyGenii 11.03.20 16:03 Сейчас в теме
(58)
ться решением, которое предлагает автор этой темы.

Не пробовали в вашем режиме совместимости (8.3.6) выгрузить в DT. Найти/Поставить сервер 1С версии 8.3.6.* и с предприятия той же версии загрузить в чистую базу выгруженный ранее DT. Сделать реструктуризацию через ТИИ. Вернуть обратно последнюю версию сервера и платформы 1С. Перерегистрировать базу на сервере 1С. Зайти в базу и снять режим совместимости ?

Некоторым это помогло, именно в такой последовательности, когда реструктуризированная база на старой платформе подходящей для текущего режима совместимости как будто открывается на только что обновленном сервере 1С с последующим снятием режима совместимости, нам увы нет.
60. Oleg_Anat 12.03.20 10:58 Сейчас в теме
(59)

Спасибо за подсказку ее одного варианта действий. Проделал все в указанной последовательности - но увы не помогло.

Вопрос еще ко всем . У меня на данный момент нет стартмани. Может ли кто то продать их или может возможны какие то другие варианты. Если есть возможность - напишите в личку.
61. ZloyGenii 12.03.20 15:57 Сейчас в теме
(60)

На выходных будут опробованы два варианта дополнительно (параллельно буду пробовать оба):

1. Выгрузка в DT (благо это отрабатывает без проблем). Загрузка в postgresql. Реструктуризация там. Если пройдет без ошибок снятие режима совместимости конфигурации. Последующая реструктуризация через ТИИ. Если пройдет без проблем выгрузка в DT и загрузка на SQL в совершенно чистую базу.

2. Если проблема с записями в DBNames и DBSchema то родилась идея за неимением возможности приобрести здешние обработки по (простите мне мой французский) конским ценам...
Собственно идея, создание копии базы на SQL (именно средствами SQL). Регистрация копии на сервере (с отключением регламентных заданий). Вход в конфигуратор копии базы. Сохранение конфигурации в CF. Удаление проблемных объектов из конфигурации с удалением ссылок на эти объекты в других объектах. Сохранение получившейся конфигурации. (на всякий случай перерегистрация базы на сервере 1С). Далее через сравнить объединить накатить сохраненную ранее CF чтобы получить ту же самую базу но с новыми объектами так сказать. Реструктуризация через ТИИ. Если проходит без ошибок то уже дальше средствами SQL копировании из починившейся базы таблиц DBNames и params, а так же config (что-то мне подсказывает что данный способ имеет место жить если все сделать правильно). Надо не забыть что в копии после всех манипуляций необходимо будет зайти и через получение структуры хранения узнать новые имена наших объектов, чтобы потом их переименовать в старой базе. (если что копия у нас будет так как мы ее делали чтобы развернуть рядом вторую базу).
63. ZloyGenii 16.03.20 09:26 Сейчас в теме
(61)

1) postgresql - результат полностью нулевой. собственно потеря времени и только.

2) не хватило места развернуться :) пока откладывается... База несколько сотен гигов а место на серваке не резиновое :( не удалось одновременно несколько испытаний провести.
64. ZloyGenii 19.03.20 08:47 Сейчас в теме
(60)

Второй вариант полностью жизнеспособен. Собственно нужно только время.
Делается копия базы (я делал две). На одной из копий, условно назовем ее 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)
Nikola_P_L; +1 Ответить
65. ZloyGenii 19.03.20 08:52 Сейчас в теме
(64)
т стал именоваться "Reference21NG" так же запоминаем какие имена получились у других справочников.
8. Копирование на SQL из базы 2 в б


Скрин новых имен баз. Странно то что объекты не продолжили нумерацию, а получили буквенные окончания.

http://joxi.ru/gmvzkMHvBoM3ma
67. Дмитрий74Чел 239 19.03.20 10:25 Сейчас в теме
(65) NG - new generation. Где-то читал в комментах что это механизм реструктуризации новый: сперва создается новая таблица "OldNameNG", потом в неё копируются данные из старой таблицы "OldName", старая удаляется, новая переименовывается в старую. Так что на мой взгляд у вас не совсем корректно получилось.
70. ZloyGenii 19.03.20 16:38 Сейчас в теме
(67)

Вы были правы насчет NG, после очередной полной реструктуризации имена таблиц изменились и нумерация продолжилась... загадка... Но тем не менее с объектами все в порядке. Уже и посоздавал элементы и помечал на удаление, выбирал в других документах все вроде бы ок на первый взгляд.

В выходные буду на боевой проводить подобный эксперимент.
66. Дмитрий74Чел 239 19.03.20 10:23 Сейчас в теме
(64) добавьте реквизиты к объектам, или лучше накатите новый релиз - проверьте точно ли все в порядке.
68. ZloyGenii 19.03.20 13:25 Сейчас в теме
(66)
или лучше накатите


Проверил вроде все ок.
Добавление реквизитов ВООБЩЕ никак не сказывалось, что только не делал. И к ним реквизиты добавлял разные. и строки и булево, и ссылки на другие справочники/документы/перечисления, объект имел прежнее наименование хоть ты тресни.... И создавал новые справочники и в них пихал реквизиты на проблемные справочники, и перекрестное создание реквизитов делали. Тупость в том что обновление проходило без проблем. А вот ТИИ - Реструктуризация падала с ошибкой.

Смена платформы так же не давала никаких результатов (пробовали поочередно откатываться до 8.3.10.*, сейчас 8.3.16.*), жили долгое время в режиме совместимости конфигурации 8.3.10

В любом случае это не рабочая база. может что-то выстрелит. Это я делал на копиях :) ибо в боевой в течении недели такие действия провести в принципе невозможно.
69. ZloyGenii 19.03.20 13:31 Сейчас в теме
(68)
сти в принципе невозможно.

(66)

Мне больше не понятна следующая картина и ответа дать никто не смог.
Дело в том что пока база находилась в режиме совместимости 8.3.10 я облазил на SQL базу вдоль и попере, таблиц начинающихся на DataHistory* вообще не было !!! Почему при ТИИ платформа ругалась на эти таблицы. Сейчас эти тпблицы появились после снятия совместимости. и теперь их хоть видно :) но почему в режиме совместимости при ТИИ платформа ругалась на эти таблицы - мне не понятно до сих пор.
71. ZloyGenii 24.03.20 13:25 Сейчас в теме
(64)

Полностью жизнеспособный вариант, вылечено несколько огромных баз. Но для моего конкретного случая, когда ни ТИИ, ни выгрузки в 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 и прочите таблицы и там переименования/перенумерации объектов (но за деньги) ? Моим способом реанимировано несколько огромных баз и все они работают без проблем на текущий момент.

На данный способ натолкнула идея прямого вмешательства в таблицы, описанного здесь, и посетила идея что если способа вмешаться напрямую нет, можно заменить эти значения из другого источника, ну а как получить нужный источник описано выше.

Спасибо за внимание.
22. Archidiavol 09.12.19 09:06 Сейчас в теме
Наша ошибка выглядела так:

Ошибка 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С, так что пробуем на копии, а потом уже на живой базе.
Дмитрий74Чел; rokhin; rps_ooo; +3 Ответить
24. Дмитрий74Чел 239 09.12.19 11:49 Сейчас в теме
(22) на данный момент по-моему самый просто вариант "добавить реквизит к объекту и обновить БД". В вашем случае - добавить к каждому проблемному объекту.
Если остался интерес и "битая" база - попробуйте.
26. rokhin 147 24.12.19 16:22 Сейчас в теме
(24) Пожалуйста объясните подробно, какие действия следует произвести для того, чтобы "добавить реквизит к объекту и обновить БД" ?
Пробовал к перечислению добавить еще одно значение, ничего не изменилось.
28. Дмитрий74Чел 239 25.12.19 13:26 Сейчас в теме
(26) реквизит к объекту, а не значение к существующему реквизиту. Например реквизит "НовыйРеквизит" типа "Справочник.Номенклатура" к справочнику "Организации".
Да, у вас проблемный объект - перечисление, а не справочник. Но попробуйте к справочнику добавить.
30. rokhin 147 25.12.19 15:44 Сейчас в теме
(28) Предполагаю, что суть добавления реквизита - вызвать при применении измененной конфигурации реструктуризацию этой таблицы.
При реструктуризации конфигуратор создает новую таблицу (с новым номером), копирует все записи в соответствии с полями, а старую таблицу удаляет, схему корректирует в соответствии с новым номером.
Таким образом дублирование исчезает.
Поэтому от добавления значения для перечисления добавится лишь запись в таблице, а создание новой таблицы не произойдет.
PLAstic; Olenik; user728723; +3 Ответить
31. Дмитрий74Чел 239 26.12.19 09:08 Сейчас в теме
(30) Да, Вы правы. Я пожалуй чушь написал.
27. rokhin 147 25.12.19 02:03 Сейчас в теме
Логика исправления вполне понятна. Приступаю.
Исправил схему, Исправил таблицу имен, переименовал таблицы.
Пересоздал базу. (удалил в 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".

Это следующий свободный номер в Таблице имен. Кто решил его занять?
В схеме и в таблице имен этого номера нет.

Тупик.
29. Дмитрий74Чел 239 25.12.19 13:28 Сейчас в теме
(27) см. (28). Если не поможет, и точно не накосячили в (27) то:
- обновиться на платформе ниже 8.3.15 (точно прокатит)
- или пробовать самую свежую платформу (не факт)
35. rokhin 147 21.01.20 10:59 Сейчас в теме
(27)
Т.е. Схема и Таблица имен в базу загрузилась.
Переименовал таблицы базы. Проверил, новые таблицы есть.

При ТиИ реструктуризация, выскочила:

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Тип поля CAST(Document251.VT34516.Fld34520 AS REF(Enum377)) AS Fld34520 несовместим с типом поля Fld34520


Спустя месяц вернулся к проблеме.
Понял. В моем случае еще и сбилась схема соответствия полей.

А релиз платформы 8.3.16.1148 проблему не решил (ТИИ)
36. Дмитрий74Чел 239 21.01.20 17:16 Сейчас в теме
(35) Стоп. У Вас там же Document.vt - это табличная часть, а в ней колонка Fld34520. Которая ссылается на что-то. Например, на справочник или перечисление.
Возможно, вы переименовали основную таблицу объекта в sql, но не учли ссылки на этот объект в других местах (например, в ТЧ у какого-то документа).
Именно поэтому рекомендую выбрать "жертву" ту, у кого нет табличных частей (и на кого нет нескольких ссылок в DBSchema).

Дайте текст ошибки вида:

Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.

Имена таблиц с кодом 1: xxx, yyy
37. rokhin 147 21.01.20 21:34 Сейчас в теме
Есть предположение из-за чего такая ошибка выскочила:
Ошибка SDBL:
Тип поля CAST(Document251.VT34516.Fld34520 AS REF(Enum377)) AS Fld34520 несовместим с типом поля Fld34520

(36)
Дмитрий, конечно это табличная часть, конечно она принадлежит документу.
Я понял, что табличные, да и все реквизиты, тоже имеют нумерацию, а у них имеется такое же сопоставление.
Оно также записано в схеме, и если сопоставление испорчено, то при проверке может не совпасть тип.
Хорошо, что то что в них записано при Реструктуризации не проверяется, проверяется только тип.
В этом и ошибка.
Теперь я это понял, и эту проблему уже исправлю. НО
Тогда я ручками это все проделывал (переименования и прочее) повторять ручками уже не хочу. Сейчас пишу обработку для этих целей.
Еще одна база проявила себя, буду автоматизировать исправление.
40. rokhin 147 23.01.20 09:53 Сейчас в теме
(27)
Enum377

Как раз, это поле пропустил, не поменял. Когда ручками трудно все уследить.
32. han_kdz 11 12.01.20 16:29 Сейчас в теме
Лично у меня было вот такое сообщение:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.

Имена таблиц с кодом 1: CKinds1, CKindsDN605
Имена таблиц с кодом 2: CKinds2, CKindsDN639
Для исправления проблемы вы можете обратиться в службу технической поддержки.


Реструктуризацию провести не смог, вываливается. База большая, около 500Г. Возможно из-за этого.

CKinds - это план видов расчета. Какой именно я не стал определять (можете поиграться со структурой, кому интересно). Я просто добавил КАЖДОМУ из плана видов расчета (у меня их всего 6) новый реквизит и ошибка исчезла!!! Затем Все эти реквизиты убрал за ненадобностью.

Релиз 1С:Предприятие 8.3 (8.3.15.1489) Конфигурация УТП (Украина)
denis83; Olga_Pro; wowik; Bernstein_13; ketr; 1cprogr_nsk; +6 Ответить
33. 1cprogr_nsk 110 12.01.20 17:56 Сейчас в теме
(32) У меня УПП ред. 1.3.116.1, после перехода на платформу 8.3.16.1063 Выдало тоже две строки с CKinds (2 и 5) , добавил реквизиты в каждом из 6 и помогло
freeek; Olga_Pro; ketr; dachnik; +4 Ответить
75. freeek 22.07.20 11:26 Сейчас в теме
(33) ошибка была один в один, УПП, таблицы CKinds2 и CKinds5.
Обработкой https://infostart.ru/public/19671/ нашел, что за объекты и добавил по одному реквизиту. Помогло.
83. denis83 12 15.02.21 09:57 Сейчас в теме
(32)

Были ошибки
Имена таблиц с кодом 888: CKinds888, CKindsDN18657
Имена таблиц с кодом 891: CKinds891, CKindsDN18674
помогло добавление / удаление реквизита в каждый - Планы видов расчета
34. dnikolaev 179 17.01.20 22:25 Сейчас в теме
Спасибо всем. поделюсь как я решил.
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.

Имена таблиц с кодом 333: CKinds333, CKindsDN863
Имена таблиц с кодом 641: CKinds641, CKindsDN671



вот таким кодом я получил соответствие таблиц SQL и метаданных

СтруктураХраненияБазыДанных = ПолучитьСтруктуруХраненияБазыДанных();

сч=1;
Для Каждого ЭлементСтруктуры Из СтруктураХраненияБазыДанных Цикл

новстр = объект.ТабличнаяЧасть1.Добавить();
новстр.реквизит1 = ЭлементСтруктуры.ИмяТаблицыХранения;
новстр.реквизит2 = ЭлементСтруктуры.Метаданные;

КонецЦикла;

КонецПроцедуры



узнал что в моем случае это были
Планывидовхаракетристик.Начисления
Планывидовхаракетристик.Удержания

добавил по реквизиту.. и обновление прошло успешно.

2) также помогло.

параллельно с этим выгружался в файловую базу.. произвел ТИИ- реструктуризацию.. в моем случае тоже помогло 8.3.16

еще раз всем спасибо.
freeek; goracio_99; +2 Ответить
72. goracio_99 09.06.20 13:07 Сейчас в теме
(34) Спасибо! Помогло, сэкономил кучу времени.
76. freeek 22.07.20 11:28 Сейчас в теме
(34) тоже помогло, использовал обработку https://infostart.ru/public/19671/ чтобы увидеть объекты по именам таблиц.
38. dubovenko_m 71 22.01.20 10:35 Сейчас в теме
ВАЖНО!!! вчера написала разработчику. получила ответ:
1С Линия консультации Вчера, 13:28
Кому: вам
Здравствуйте!
Присылайте базу в ремонт. Самостоятельно не лечится.
Вам предоставлен ресурс для передачи службе технической поддержки дополнительных файлов ,
в рамках вашего обращения (#HL-106678) , просьба загружать данные только относящиеся к этому обращению.
42. Дмитрий74Чел 239 24.01.20 09:10 Сейчас в теме
(38) Конечно "не лечится". Ведь конфигуратор не может исправить ситуацию (которую вообще-то сам и породил), а по внесению изменений на уровне sql - оф.позиция 1С "в sql лезть нельзя".
43. Дмитрий74Чел 239 24.01.20 09:19 Сейчас в теме
(38) А вообще интересно, что они вам дальше ответят и как "быстро" вернут базу. Или будет исправленный cf (вряд-ли)?
39. rokhin 147 23.01.20 09:35 Сейчас в теме
Вручную эту методику реализовать не удалось, трудно сделать все аккуратно, повторять было лень, пришлось писать обработку.
https://infostart.ru/public/1183875/
Никаких замечаний по несоответствию поля уже не было. Видимо ручками что-то испортил.
А с обработкой прошло все гладко. Даже не сбрасывал кэш, не производил "тестирование и исправление" базы.
cdiamond; r.zdorkin; Дмитрий74Чел; +3 Ответить
41. Дмитрий74Чел 239 24.01.20 09:09 Сейчас в теме
44. dubovenko_m 71 24.01.20 09:33 Сейчас в теме
Вернули базу через день. хотя обещали сутки. и на вторые мы уже ругательные письма писали. без комментов о причинах ошибки.
45. Veika 25 03.02.20 11:16 Сейчас в теме
А нельзя просто исправить базу через тестирование и исправление информационной базы с установленным флажком "Реструктуризация таблиц информационной базы"?
47. Дмитрий74Чел 239 03.02.20 18:11 Сейчас в теме
(45) На данный момент - нет.
48. Veika 25 03.02.20 18:59 Сейчас в теме
И как теперь обновляться? Даже как-то страшно...
49. Дмитрий74Чел 239 04.02.20 08:32 Сейчас в теме
(48) Выпить валерианки. Нажать "обновить". При неполадках скачать (39).
50. Veika 25 04.02.20 10:14 Сейчас в теме
Нет, ну я же серьезно, это что может быть у всех...
51. Дмитрий74Чел 239 04.02.20 10:19 Сейчас в теме
(50) И я серьезно. У всех, кто менял конфигурацию.
52. pavel_pss 290 12.02.20 17:10 Сейчас в теме
на 1С:Предприятие 8.3 (8.3.16.1063) до сих пор вылезает
55. iones 197 03.03.20 11:37 Сейчас в теме
Помогло добавление нового реквизита. Выгрузка в DT и загрузка в новую не помогла.
73. itikhomirov 10.06.20 09:12 Сейчас в теме
В случае плана видов расчета помогло добавление кода предопределенным элементам. Думаю поможет и просто добавление предопределенного элемента.
Прикрепленные файлы:
74. devonec_team 36 25.06.20 13:40 Сейчас в теме
Помогло ТиИ. Платформа 1С:Предприятие 8.3 (8.3.16.1224)
77. user949348 19.08.20 10:57 Сейчас в теме
Еще один вариант "танцев с бубном".
Если есть где развернуть 1с сервер с предыдущей платформой, переключаем на него базу, опять же добавляем реквизиты в проблемные объекты и обновляемся, потом на новой платформе проблем нет, это если по какой то причине не поможет добавление реквизитов на новой платформе.
78. PbI4 2 13.10.20 00:44 Сейчас в теме
8.3.18.1128 - проблема не исправлена, так что это не баг - это фича(
Дмитрий74Чел; +1 Ответить
79. Nikola_P_L 23.10.20 14:35 Сейчас в теме
Может кому поможет
Платформа 8.3.16.1063
Ошибка SDBL: Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных. Имена таблиц с кодом 18: ExtensionsInfoNGS, Reference18 Имена таблиц с кодом 19: ExtensionsRestruct, Reference19 Имена таблиц с кодом 20: ExtensionsRestructNGS, Reference20 Имена таблиц с кодом 24: DataHistoryMetadata, Reference24
Это таблицы справочников банк, банковские счета, виды контактной информации и адресные сокращения
При реструктуризации те же ошибки
Пробовал добавлять реквизиты, загружать в чистую базу, в файловом и клиент серверном режиме ничего не помогало
Решение с удалением таблиц и загрузкой из CF помогло, но не удалось вернуть данные

Помогло следующее:
Создал узел для базы (РИБ), потом отвязал эту базу от основной и реструктуризация прошла успешно. Можно работать в этой базе только нужно заново активировать пользователей
Дмитрий74Чел; +1 Ответить
80. dikar40 9 02.11.20 16:40 Сейчас в теме
(8) Помогло добавление реквизита к "проблемным" объектам.
81. lev6975 14.01.21 00:12 Сейчас в теме
Спешу огорчить сообщество, у кого такие ошибки, на платформе 8.3.18.1208 добавления реквов в объекты НЕ работает! Ошибка остается
Или я чего - то делаю не так?
Я делаю:
1) Открываю проблемный документ
2) Перехожу в "Данные"
3) Добавляю любой реквизит
4) Сохраняю конфу БД, все верно?
В общем не работает этот метод. Платформа 8.3.18.1208, конфа файловая.
Поправьте если чего не так сделал...
P.S. И вообще, немного непонятно, почему это должно помочь - ведь идентификатор таблицы документа при добавлении реквизита не меняется!
user1503726; +1 Ответить
82. lev6975 14.01.21 14:25 Сейчас в теме
(81) P.S. Ну и радостная новость - ТИС спасает от этой напасти - платформа 18. Долго там чего - то крутит - крутит, ошибок никаких не пишет но в конце дает обновить конфигурацию БД
84. user1239818 22.02.21 12:42 Сейчас в теме
УПП 1.3.153.2 на 8.3.18.1208. Помогло добавление реквизитов в ПланыВидовРасчетов ОсновныеНачисленияОрганизаций и УправленческиеНачисления
NikolaST; Хряк; +2 Ответить
89. Хряк 144 09.08.21 09:45 Сейчас в теме
(84) Аналогично на УПП 1.3.159.1 и 8.3.18.1289. Добавил реквизиты в ПланыВидовРасчетов ОсновныеНачисленияОрганизаций и УправленческиеНачисления, - ошибка ушла.
85. user689995_qalitek 15.04.21 07:21 Сейчас в теме
Можно, конечно что-то добавить, потом это что-то удалить, но это все от лукавого.
В данном случае помогла простая штатная процедура.

Пердистория:
Пользовали платформу 8.3.18.1334 в режиме клиент-сервер. У нее есть глюк впадать в коматозное состояние с загрузкой процессора под 80-90% и потерей сетевых подключений. В результате чего возникли проблемы с добляжем ссылок.

Теперь о главном. Тестирование и исправление, загрузка-выгрузка не спасли отца русской демократии.
Создвл пустую базу из шаблона последнего обновления БП в файловом варианте.
В другую файловую базу загрузил выгрузку из битой БД.
Настроил штатными средствами синхронизацию БП->БП
Сначала перенес справочники, затем перенес документы и выполнил закрытие месяца от царя гороха до текущего.
Выгрузил БД и загрузил в SQL
Ошибка ушла.
86. Дмитрий74Чел 239 15.04.21 12:01 Сейчас в теме
(85) Ну вы блин даете (с)
Закрытие месяца от времен царя гороха.

Чтоб цифры "поплыли"? На реальных базах многолетних такое не прокатит. Я уж не говорю что базы коллег очень часто в файловые не помещаются, т.к. занимают сотни Гб.
87. user689995_qalitek 15.04.21 12:18 Сейчас в теме
(86) Тоже и в SQL прокатит. Принцип не трансляция таблиц с косяками, а перенос живого документа без танцев с бубном в конфигураторе...
ЗЫ
Вообще, закрытие месяца он сам предложит от начала и до месяца по выбору....
88. it-expert 02.06.21 11:31 Сейчас в теме
(87)угу и поплывет баланс
90. N_s_s 3 15.03.22 06:20 Сейчас в теме
Помогла просто выгрузка в DT и повторное принятие изменений, обновление прошло.
91. djslon16 27.03.22 10:05 Сейчас в теме
Была такая же проблема в двух таблицах.
Тестирование и прочие шаманства не помогли.
только добавление реквизита точно в нужный объект
92. isiirk32 11.09.24 03:52 Сейчас в теме
Запросы для MSSQL без всяких обработок и конверторов (в студии получите не все данные, я делал в своей обработке):

// получить 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'

Почему то лишние пробелы вставляются в текст, не знаю что тут с комментариями