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

   Bibr

12.07.19 — 11:24

   Timon1405

1 — 12.07.19 — 11:33

   Bibr

2 — 12.07.19 — 11:35

   Bibr

3 — 12.07.19 — 11:36

   zva

4 — 12.07.19 — 11:43

   Timon1405

5 — 12.07.19 — 11:46

   Bibr

6 — 12.07.19 — 14:15

(4)

один в один. Спасибо

   ILM

7 — 19.07.19 — 06:37

   LastSova

8 — 28.07.19 — 09:44

Уважаемый Bibr, удалось забороть проблему?

   vaseha_vs

9 — 31.07.19 — 04:38

(0)

Здравствуйте! Не могли бы вы подсказать как просмотрели структуру базы данных?

Возникла на такой же платформе(8.3.15.1489), эта же ошибка (Ошибка SDBL)… Новенькая в этом деле, пытались перезагрузить сервер и кэш, и откатывать до рабочей версии, до внесения изменений, все равно выскакивает ошибка.

   ИгорьП

10 — 31.07.19 — 08:20

Мне техподдержка 1С посоветовала провести ТИИ с флажком реструктуризации. В выходные буду делать, о результатах отпишусь

   hhhh

11 — 31.07.19 — 08:29

(9) да, при переходе на новую платформу обязательно тии делайте. А если файловая база, то вообще делайте тии раз в неделю, по пятницам. Даже если платформа нее меняется.

   vaseha_vs

12 — 31.07.19 — 10:16

(10) (11)

Благодарю, Уже процесс запущен:)

(10) Будем ждать результатов, надеюсь у Вас все будет отлично

   ИгорьП

13 — 01.08.19 — 22:10

(12) На тестовой получилось. Итак, решение: ТИИ с флажком реструктуризации (я ставил 1 этот флажок)

   NewSage

14 — 01.08.19 — 22:18

Это ошибка последних версий платформы.

Для работы со старыми конфигурациями понизьте релиз до 8.3.13.1865.

   ILM

15 — 02.08.19 — 14:01

(14) Когда по правят?

   Sergz66

16 — 02.08.19 — 14:12

(14) У меня на 8.3.13 ошибка проявлялась, вылечилась ТиИ с реструктуризацией.

   Волшебная клизма

17 — 27.08.19 — 16:01

(0) короче на КА при установке 8.3.15 при обновлении вылезла такая же штука, это проблема платформы, помогло:

создание новой базы на 8.3.12, загрузка туда dt , и уже обновление платформы на 8.3.12

Если этот же dt загружать на 8.3.15, то вылазиет именно эта ошибка

   Ирина Ап

18 — 21.09.19 — 14:59

Спасибо всем, кто подсказал про тестирование и исправление, после этого обновление пошло, как по маслу, а до этого мучилась, платформы меняла 2 недели!

   cons24

19 — 02.10.19 — 10:24

   PivaSOS

20 — 24.10.19 — 23:38

зарегился, чтобы Клизме спасибо сказать! (17)

   Ёпрст

21 — 25.10.19 — 00:31

Всё проще, для ошибки как в (0) надо в плане вида расчета добавить реквизит, сохранить конфу — тогда обновление пройдет, потом прибить реквизит.

Там 2 плана — управленческие начисления и начисления по организации.

Усё.

А запуск ТиИ с  реструктуризацией, на большой базе, это можно и не дождаться. Да и не надо.

(21) +100500/ только сначала всё повторить на копии. Для тех кто в танке, копию делать не через выгрузку DT.

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

После перехода с 8.3.12 на 8.3.15 словили неприятную ошибку «Для одного ссылочного кода существует более одной таблицы в базе данных». Самое неприятное, что ошибка стала вылезать и на типовых базах, которые никто никогда не трогал.

Гугл ничего не дал кроме стандартных «почистить кэш, перерегистрировать базу в кластере, выполнить ТИИ». Ну и еще «добавить реквизит к объекту и обновить БД» (этот пункт не пробовал, напишите в комментариях — вдруг это самый простой метод в комментариях к этой статье есть сообщение что метод сработал на 8.3.16.1030, пробуйте).

На партнерке есть пара веток, в т.ч. https://partners.v8.1c.ru/forum/topic/1792992, из которой приведу пару цитат:

Воспроизводится так (проверено на релизе 8.3.13.1644 / SQL 2023):
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) к данной статье коллега отписался о неэффективности этого метода.

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

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

Кроме того данная ошибка уже исправлена версиях платформы 8.3.12.1924, 8.3.13.1865, 8.3.14.1694, 8.3.15.1489.

Как возникает проблема и как ее избежать

Воспроизведение достаточно простое:

1. Делаем резервную копию ИБ средствами СУБД;
2. Добавляем в ИБ объект конфигурации. В СУБД будет добавлена таблица с типом объекта и ссылочным кодом. Например _DocumentChngR26630;
3. Восстанавливаем ИБ средствами СУБД из резервной копии созданной в пункте 1;
4. Добавляем в ИБ объект конфигурации отличный от добавленного в пункте 2. В СУБД будет добавлена таблица с типом объекта и дублирующимся ссылочным кодом. Например _InfoRg26630;

Как результат дальнейшее обновление конфигурации базы данных прерывается с указанной ошибкой.

Данный сценарий вполне можно получить при работе в тестовом контуре, выполняя обновлениие тестовой ИБ данными резервной копии продуктивной ИБ.

Для избежания данной проблемы необходимо выполнить перезапуск сервера 1С:Предприятия сразу после восстановления ИБ из резервной копии средствами СУБД, или работать на версиях платформы начиная с 8.3.12.1924, 8.3.13.1865, 8.3.14.1694, 8.3.15.1489.

Но если счастье уже наступило ошибка уже имеется в наличии, то исправлять придется самостоятельно.

Как устранить проблему

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

Определение проблемных объектов

Для этого воспользуемся методом ПолучитьСтруктуруХраненияБазыДанных(), точнее напишем небольшой кусочек кода:

В полученном тексте найдем записи с указанными таблицами в сообщении об ошибке

Из полученного видно, что РегистрСведений.СостоянияБлокировкиВычетаНДСПоСчетамФактурам конфликтует с Константа.CRM_ПарольПользователяСинхронизацииiCRM и Документ.CRM_ШаблонЭтапаКалендарногоПлана.

Определение жертвы

Теперь необходимо исходя из наполнения ИБ и важности объектов решить какой из них удалить. В разбираемом примере РегистрСведений.СостоянияБлокировкиВычетаНДСПоСчетамФактурам оказался пуст, его и будем удалять.

Если объект содержит данные, тогда необходимо обеспечить возможность возвращения данных в исходное состояние. Например обработкой из инструментов разработчика ВыгрузкаЗагрузкаДанныхXML выполнить выгрузку данных в файл.

Удаление метаданного

Если метаданное стоит на поставке, тогда необходимо снять его с поставки. Для этого перейдем в меню Конфигурация — Поддержка — Настройка поддержки, в дереве матаданных найти необходимый объект и установить правило поддержки Объект снят с поддержки и установить признак Установить для подчиненных.

Теперь необходимо выполнить попытку удаление. Если на объект есть ссылки, то выведется сообщение об нерешенных зависимостях: “Объект не может быть удален, так как на него имеются ссылки в других объектах”.

Заходим в каждый из них, убираем ссылки, после удаляем сам объект.

Теперь, если все выполнено правильно, обновление конфигурации базы данных пройдет без проблем.

Реструктуризация таблиц информационной базы

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

Для этого необходимо перейти в меню Тестирование и исправление, и выполнить реструктуризацию таблиц информационной базы.

Восстановление метаданного и данных

Теперь настала пора вернуть конфигурацию к ее начальному состоянию. Удаленный объект, и ссылки на него в других объектах возвращаются путем сравнения и объединения с сохраненной ранее конфигурацией или конфигурацией поставщика .

Если в удаляемом объекте были данные, тогда необходимо выполнить их восстановление, например обработкой из инструментов разработчика ВыгрузкаЗагрузкаДанныхXML.

Собственно все! Таким нехитрым способом устранили ошибку «Для одного ссылочного кода существует более одной таблицы в базе данных».

Может возникнуть ситуации, когда конфликтующие метаданные одинаковы. Ошибка характерна для планов видов расчета. Для исправления необходимо в проблемный план видов расчета добавить любой реквизит и обновить конфигурацию ИБ, произойдет реструктуризация, после чего проблема исчезнет. После исправления не забываем удалить реквизит, если он не нужен.

Данная ошибка может возникнуть даже при разворачивании пустой ИБ из шаблона поставки ЗУП 2.5 или УПП.

Источник

Ошибка SDBL в 1С

• 

Возникновение ошибки SDBL

Ошибка SDBL возникает, когда происходит обновление конфигурации 1С:Предприятие или сохранение перемен. Также сообщение об ошибке может возникать при работе с обменами данных:

Рис. Сообщения 1С об ошибке SDBL

Также к данным сообщениям часто есть одна или несколько приписок:

• была совершена попытка вставить значение с недопустимым типом;
• был совершён пропуск точки с запятой;
• имеет место ошибка, которая произошла при индексировании с полным текстом;
• некоторое поле имеет неоднозначное определение;
• не хватает выражения (pos =);
• совершён выход из размерностей;
• в поле таблицы используется невозможный тип значения «NULL».

Обратите внимание: есть вероятность, что при ошибке будут другие сообщения, не указанные выше!

Устранение ошибки SDBL в 1С

Устранить ошибку SDBL можно одним из способов, которые описаны ниже.

1. Сделать перезагрузку на сервере с приложениями для 1С 8.3. Далее может помочь, если включить и выключить все сервисы SQL и агентами SQL. Для этого потребуется зайти на сервер, выбрать «Агент сервера 1С» и при помощи контекстного меню приостановить работу. По аналогии сделаем с «Агентом SQL» и «SQL Server» для сервера SQL. Затем следует снова подключить их, но в обратной последовательности.

2. Выгрузить базу с данными в некоторый файл, который будет иметь расширение DT, а затем выгрузить её назад – в ту же базу с информацией. Аналогично будет исполняться для режима конфигуратора при помощи вкладки меню «Администрирование» – посредством использования команд «Загрузить информационную базу…» и «Выгрузить информационную базу…».

3. Можно попробовать очистить КЭШ внутри сервера и внутри компьютера пользователя в месте, где была обнаружена ошибка. Для этого потребуется закрыть 1С, далее совершить поиск по папкам, которые будут иметь имя вида «bd5c8ea4-b65f-4c23-a9c8-2dccfb0b15fa» внутри папки с названием «Application Data», после их нахождения производим удаления данных папок.

4. Также можно обновить платформу на более современную версию (с главного портала – ИТС). Для выполнения данного действия скачиваем с ИТС новую платформу 1С 8.3 и устанавливаем ее на компьютерах клиентов и на сервере.

5. Рассмотрим еще один вариант – использование механизма «Тестирование и исправление информационных баз», который находится внутри конфигуратора. В необходимой базе переходим по пути: «Администрирование → Тестирование и исправление информационных баз», а далее запускаем процесс.

6. Совершим загрузку внутри копии, которая является резервной, если она была создана в недавнем времени. Замечание: обязательно часто делать резервные копии до любого важного действия с ИБ. Копии делаются посредством SQL MS или конфигуратора, при этом происходит выгрузка файла в формат dt.

Если ни один из вышеперечисленных способов не устранил ошибку SDBL, следует произвести очистку таблиц _ConfigChngR_ExtProps и _ConfigChngR. Однако для этого потребуется знания принципов работы MSSQL.

Источник

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

Ранее проблема решалась

Мои решения.

Вариант №1. Запускаем конфигуратор под платформой 8.3.14.*

Нажимаем кнопку Обновить конфигурацию базы данных

Запускаем предприятие версии платформы 8.3.15.*

Повторяем для каждого обновления.

Минус, нужно так делать при каждом обновление.

Вариант №2: всё делаем на платформе 8.3.15.*

У нас есть список проблемных таблиц. Нужно узнать их имена в 1С. Для этого используем «Иструмент разработчика» или аналоги для сопоставления внутренних имён и имён в конфигураторе 1С.

В моём случае это было 2 справочника и 1 План обмена.

1) Проверяем в режиме предприятие что содержится в данных справочниках или регистрах. Если они пустые, то можно удалить объекты из конфигуратора.

2) Для удаления, снимаем с поддержки конфигурацию.

3) После удаления пустых таблиц, добавим столько же объектов в БД.

4) Сохраняем конфигурацию, режим предприятия нам не нужен.

5) Обновляем БД меню->Конфигурация->Загрузить конфигурацию из файла

Далее, далее, далее….

6) Нажимаем кнопку Обновить конфигурацию базы данных.

7) запускаем режим предприятие. Проверяем работоспособность.

Из минусов, не каждые объекты можно удалить без болезненно.

Вариант №3

Похож на вариант №2 , Вместо удаление проблемных объектов, добавляем реквизит в них.

полноценно его не тестировал, в некоторых случаях помогает

Источник

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

Доброго времени суток!

Тема, давно знакомая многим, и на многих форумах писали об этой проблеме. А проблема заключается в следующем:

При поднятии версии платформы или режима совместимости выходит ошибка

В процессе обновления информационной базы произошла критическая ошибка

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

Имена таблиц с кодом 7289: DynListSettings, ErrorProcessingSettings

Имена таблиц с кодом 7291: Bots, ExtensionsInfo

Для исправления проблемы вы можете обратиться в службу технической поддержки.

В общем, расскажу, как решил и как боролся с этой проблемой. Итак, начнем.

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

Начал искать, в чем проблема, нашел в конфигурации пару справочников, которые просто болтались в конфе и никак, нигде не участвовали, не имели реквизитов и, видимо, просто были добавлены кем-то когда то, удалил их, запустил ТиИ с реструктуризацией и, о чудо, помогло. Я довольный, думал, все, решил проблему, но при поднятии режима еще на одну выше опять та же ошибка. Начал копать глубже, начал смотреть саму структуру хранения. Нашел эти таблицы и ничего толкового не смог понять.

Решил копать в сторону SQL. Раскрыв ветку с таблицами именно этой БД (условно БД1), нашел эти таблицы и решил попробовать удалить индексы таблицы, но тоже не помогло, пробовал пересоздать таблицы и тоже безрезультатно, скопировать с другой рабочей БД, но тоже самое.

Загрузил .cf в пустую БД (условно БД2) и попробовал там, и поднялось вообще без проблем. Значит, проблема в данных самой БД1. Решил перекинуть данные из БД1 в БД2, сначала пробовал средствами самой 1С. Перекинул, сверил итоги, вроде все норм. Думаю УРА. но стоило добавить какой либо реквизит, и все, ошибка. Решил перекинуть с самой SQL. Но опять тоже самое.

Пробовал выгрузить файлы конфигурации и там поискать что-то похожее на эти таблицы, но безрезультатно.

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

Запустил, вроде прошла норм, делаю ТиИ тоже без ошибок, поднимаю версию и на тебе, опять ошибка. Иду в SQl, нахожу эту таблицу и пересоздаю ее опять, и заново запускаю ТиИ. Прошло без ошибок, поднимаю версию, опять ошибка. Посидев и понаблюдав за ходом ТиИ, заметил, что ошибка выскакивает на пересчете итогов, решил добавить реквизит в регистр бухгалтерии и регистр накопления, запустил ТиИ и все норм прошло, обновился и тоже норм прошло. Поднимаю версию, и вот оно ЧУДО, все сработало. Удаляю добавленные реквизиты и обновляюсь, норм. Пробую добавить реквизиты в другие места, тоже норм, сам себе не верю, что получилось.

Думаю, раз уж помогло добавление реквизитов, думаю попробовать просто сразу добавить реквизиты и поднять версию, но нет, так не прокатило))).

Вывод надо через обработку потом в самой SQL, потом добавить реквизиты сделать ТиИ и потом норм будет.

Источник