Содержание:
1. Возникновение ошибки SDBL
2. Устранение ошибки SDBL в 1С
Приветствую, коллеги! В данной статье будет рассмотрена знакомая и набившая оскомину многим специалистам 1С ошибка SDBL, а также возможные пути её устранения.
1. Возникновение ошибки SDBL
Ошибка SDBL возникает, когда происходит обновление конфигурации 1С:Предприятие или сохранение перемен. Также сообщение об ошибке может возникать при работе с обменами данных:
Рис. 1 Сообщения 1С об ошибке SDBL
Также к данным сообщениям часто есть одна или несколько приписок:
· была совершена попытка вставить значение с недопустимым типом;
· был совершён пропуск точки с запятой;
· имеет место ошибка, которая произошла при индексировании с полным текстом;
· некоторое поле имеет неоднозначное определение;
· не хватает выражения (pos =);
· совершён выход из размерностей;
· в поле таблицы используется невозможный тип значения «NULL».
Обратите внимание: есть вероятность, что при ошибке будут другие сообщения, не указанные выше!
2. Устранение ошибки 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.
Специалист компании «Кодерлайн»
Айдар Фархутдинов
11.10.18 — 17:09
Для начала, сразу скажу, что ТИИ базы со всеми галками до обновления сделано, ошибок не выдает.
Конфа БП 3.0.64.54 полностью типовая.
cfu встает без проблем, конфа сохраняется, изменения применяются по F7 успешно.
Потом при обновлении в режиме предприятия падает вот так:
{Справочник.ИдентификаторыОбъектовМетаданных.МодульМенеджера(1713)}: Ошибка при вызове метода контекста (Записать)
ТаблицаОбъект.Записать();
по причине:
Ошибка при выполнении обработчика - 'ПередЗаписью'
по причине:
{ОбщийМодуль.СтандартныеПодсистемыСервер.Модуль(902)}: Ошибка при вызове метода контекста (Добавить)
Объект.ОбменДанными.Получатели.Добавить(Получатель);
по причине:
Несоответствие типов (параметр номер '1')
Это Процедура ЗарегистрироватьОбъектНаВсехУзлах(Знач Объект, Знач ИмяПланаОбмена, Знач ВключаяГлавныйУзел = Истина) Экспорт
Падает при ИмяПланаОбмена = «Полный».
Если ИмяПланаОбмена = «АвтономнаяРабота», то проходит без проблем.
Код процедуры такой:
ТекстЗапроса =
"ВЫБРАТЬ
| ПланОбмена.Ссылка КАК Получатель
|ИЗ
| ПланОбмена.[ИмяПланаОбмена] КАК ПланОбмена
|ГДЕ
| ПланОбмена.Ссылка <> &ЭтотУзел
| И НЕ ПланОбмена.ПометкаУдаления";
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "[ИмяПланаОбмена]", ИмяПланаОбмена);
Запрос = Новый Запрос;
Запрос.УстановитьПараметр("ЭтотУзел", ПланыОбмена[ИмяПланаОбмена].ЭтотУзел());// возвращает Неопределено, хотя должно возвращать ссылку на предопределенный элемент плана обмена
Запрос.Текст = ТекстЗапроса;
Получатели = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Получатель");
ГлавныйУзел = ПланыОбмена.ГлавныйУзел();
Для Каждого Получатель Из Получатели Цикл
Если Не ВключаяГлавныйУзел И Получатель = ГлавныйУзел Тогда
Продолжить;
КонецЕсли;
Объект.ОбменДанными.Получатели.Добавить(Получатель);// падает здесь
КонецЦикла;
Если в отладчике попробовать получить значение переменной Получатель, возвращает «Ошибка SDBL: Таблица или поле ID не содержится в разделе FROM».
Эту ошибку можно обойти в отладчике, заменив значение ИмяПланаОбмена = «Полный» на «АвтономнаяРабота» в начале процедуры.
Но потом после того как обновление установится, при попытке сделать ТИИ с галкой «проверка логической целостности» сразу выдается ошибка в виде предупреждения и ТИИ останавливается:
Microsoft SQL Server Native Client 11.0: Нарушено "PK___tmpRCT__80E37C38266317B0" ограничения PRIMARY KEY. Не удается вставить повторяющийся ключ в объект "dbo._tmpRCT". Повторяющееся значение ключа: (0x0000001b). HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2627, line=1
Т.е. фактически на выходе получаем битую базу.
1 — 11.10.18 — 17:27
поняли. а что хотели? предупредть ?
2 — 11.10.18 — 17:32
(1) Что делать чтобы обновилось без этой ошибки?
Всё делал на тестовой базе.
Рабочую, естественно, оставил пока на релизе 3.0.64.54.
Но рано или поздно придётся обновлять, а тут такая Ж.
Может быть кто-то уже столкнулся с тем же самым и смог победить.
3 — 11.10.18 — 17:33
Более свежий релиз платформы попробуй, из 12ых
4 — 11.10.18 — 17:34
(2) вы не первый, кто жалуется на ошибки при переходе на этот релиз. Поэтому лучше переждать
5 — 11.10.18 — 17:39
Да, забыл уточнить, что никакого РИБ в помине нет. Это одиночная база.
6 — 11.10.18 — 17:41
(3) Я понимаю, что это баг платформы, а не конфы.
Из более свежих только 2 версии 8.3.12.1616 и 8.3.12.1685.
В описании исправленных багов нечто отдаленно похожее нашёл, но не совсем оно:
При выполнении тестирования и исправления информационной базы, в которой определены разделители, при тестировании служебных таблиц некоторых объектов может происходить ошибка вида Ошибка SDBL: таблица или поле Fld2683 не содержится в разделе FROM (pos=7)
Исправлена: «Технологическая платформа», версия 8.3.12.1685
7 — 11.10.18 — 17:41
(0) Последнюю платформу (8.3.13) не пробовал ставить?
8 — 11.10.18 — 17:46
(7) Я таким экстримом не занимаюсь))
Обновляю платформу только по надобности и не на самый последний релиз.
9 — 11.10.18 — 17:54
Файловая без ошибок обновилась на 3.0.65.80.
Правда пустая.
Платформа 8.3.12.1616.
10 — 11.10.18 — 17:57
(9) Демо-база БП у меня без ошибок обновилась до 3.0.65.80 на платформе 8.3.12.1595.
А вот копия реальной базы — фиг.
11 — 11.10.18 — 21:13
(10) значит ТЖ в руки и исправляйте ошибку.
12 — 14.10.18 — 23:26
Та же самая ошибка на последней платформе 8.3.13.1513.
(11) Как надо настроить тех.журнал, чтобы попытаться самостоятельно отловить ошибку?
13 — 14.10.18 — 23:40
(12) всё ж таки проверьте планы обмена. наверняка левый узел там кто-то создал.
14 — 15.10.18 — 04:32
Ошибка зарегистрирована?
15 — 15.10.18 — 10:21
(13) Это я первым делом проверил.
В плане обмена «Полный» только один предопределенный элемент без кода, наименования, т.е. который не использовался никогда.
По остальным планам обмена на всякий случай тоже посмотрел.
У всех остальных, кроме 3-х (ниже), точно такая же картина с одним предопределенным элементом.
"Обновление информационной базы" -- кроме предопределенного еще 5 обычных элементов. "Синхронизация данных через универсальный формат" -- 2 элемента: один предопределенный и еще один обычный элемент. "Управление торговлей, редакция 11" -- 2 элемента: один предопределенный, а второй помечен на удаление.
16 — 15.10.18 — 10:21
(14) Еще в субботу написал на v8, но, такое ощущение, что по выходным они почту не обрабатывают.
17 — 15.10.18 — 10:44
Только вот сейчас ответили «Ваше письмо будет рассмотрено в ближайшее время».
18 — 15.10.18 — 10:55
(15) ну вот, тот что помечен на удаление, удалите нахрен. Бывших узлов не бывает.
19 — 16.10.18 — 07:25
Я обновился без проблем.
20 — 16.10.18 — 10:06
(18) Его невозможно удалить, на него куча ссылок, т.к. раньше до EnterpriseData этот обмен использовался.
Да и я думаю он никак не влияет, какой-то косяк с планом обмена Полный, а не с ним.
21 — 16.10.18 — 10:06
(19) Поздравляю!
А мне даже еще не ответили в какую сторону хотя бы копать.
22 — 16.10.18 — 10:08
(20) вот именно он и влияет. Так что тянуть с удалением нет смысла.
23 — 16.10.18 — 10:46
Обновил в выходные типовую рабочая базу. Без проблем обновилась и работает на рекомендованной платформе 8.3.12.1529 (правда в базе не используются синхронизации)
24 — 16.10.18 — 12:12
(23) У пользователей с ограниченными правами при поиске в динамическом списке (например в документах реализации) ошибок не возникает?
25 — 16.10.18 — 12:45
(21) Ответили, ты не захотел увидеть
В (3) этот ответ прозвучал. Я на платформе 8.3.12.1685 обновился успешно, только долго адски
26 — 16.10.18 — 12:47
(21) У меня при запуске самописки на 8.3.12 в планах обмена самопроизвольно очистились значения реквизита «ЭтотУзел» у всех узлов всех планов обмена, и тоже посыпались ошибки. После «ручной» установки значений все заработало. Проверь на всякий случай.
27 — 16.10.18 — 14:22
(25) Пробовал на платформах 8.3.12.1595, 8.3.12.1685, 8.3.13.1513 — результат одинаковый как в (0)
28 — 16.10.18 — 14:23
Попробовал выгрузить базу в dt-файл и загрузить обратно. Не помогло.
29 — 16.10.18 — 14:25
(26) А как это сделать?
После наката обновления по F7 и старта базы как-то можно отказаться от запуска обновления в предприятии?
30 — 16.10.18 — 14:29
(0) Попробуй запустить тестирование(без исправления) с 4я первыми галками сразу после завершения обновления в конфигураторе, была такая беда с типовой — помогло.
31 — 16.10.18 — 14:43
(26) В окне «Не удалось выполнить обновление» есть кнопка Еще — Открыть внешнюю обработку.
Запустил внешнюю обработку с таким кодом:
Сообщить(ПланыОбмена.Полный.ЭтотУзел().ЭтотУзел);
Выдает «Да».
Т.е. значение реквизита не слетело.
32 — 16.10.18 — 14:45
(29) Нет, после наката только из архивной копии
33 — 16.10.18 — 14:51
(31) я бы и остальные планы обмена так проверил, не только полный. Ведь в (0) явно ошибка в каком-то узле обмена. В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.
34 — 16.10.18 — 15:25
(30) Попробовал.
Если сразу после завершения обновления в конфигураторе запустить ТИИ (т.е. даже без запуска предприятия), то вываливается с сообщением, описанным в (0)
Microsoft SQL Server Native Client 11.0: Нарушено "PK___tmpRCT__80E37C38266317B0" ограничения PRIMARY KEY. Не удается вставить повторяющийся ключ в объект "dbo._tmpRCT". Повторяющееся значение ключа: (0x0000001b). HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2627, line=1
Т.е. до обновления ТИИ проходит без ошибок, после обновления в конфигураторе — база поломанная. Релиз платформы последний. Фирма 1С молчит как партизан.
35 — 16.10.18 — 15:44
У меня было слегка похожая ситуация при переходе БП 2.0 -> 3.0
Таблица была «dbo._AccRgAT2486», SQL ругался на неуникальность конкретного индекса. В Management Studio я временно разрешил этому конкретного индекса пропускать повторяющиеся значения,а после выполнения всех процедур обратно запретил.
Но что за таблица «dbo._tmpRCT»?
36 — 16.10.18 — 15:57
(34) вышел еще 84 релиз БП мож там поправили,как вариант попробуй в файловый вариант сконвертить и там обновить
37 — 16.10.18 — 17:40
(35) При ТИИ создается такая таблица в скулевской базе:
CREATE TABLE [dbo].[_tmpRCT]( [TabID] [binary](4) NOT NULL, PRIMARY KEY CLUSTERED ( [TabID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]
И даже данные в ней есть, 1189 строк.
0x0000001B — строка с таким значением есть.
Хз почему пытается вставить в эту таблицу еще одно такое значение. Естественно, скуль не даёт это сделать.
38 — 16.10.18 — 17:42
(36) Попробовал накатить 3.0.65.84 релиз. Ошибка та же.
39 — 16.10.18 — 17:56
При ТИИ базы до обновления в таблице _tmpRCT это значение 0x0000001B так же есть, но количество строк в таблице 1268 (больше).
Т.е. получается на базе после обновления спотыкается на дублирующимся ключе и недозаполняет таблицу.
Где хранится обратная связь ID таблиц с человеческим наименованием?
Чтобы хотя бы попытаться понять что где задублировалось при обновлении.
40 — 17.10.18 — 07:49
(39)для таких целей писал обработку, если нужна напиши почту — скину
https://cloud.mail.ru/public/DTQ1/B9ZWfDtnW типо так умеет
41 — 17.10.18 — 14:44
(40) Спасибо, кончено, но это немного не то.
Значения в таблице _tmpRCT:
0x00000008 0x0000000A 0x0000000B ... 0x0000001A 0x0000001B 0x0000001C .. 0x000078B4 0x000078B5
Т.е. какой-то внутренний ID таблицы, а не её имя.
Но количество строк странное.
Чуть больше 1 тыс. даже в нормальной базе, хотя таблиц в базе больше 5 тыс.
42 — 17.10.18 — 15:10
с помощью ddl триггера отключите индекс
43 — 17.10.18 — 23:30
(33) >я бы и остальные планы обмена так проверил, не только полный
Вот такой код выдает «Да» и в битой базе после обновления, и в нормальной до обновления:
Для Каждого ТекПланОбмена Из Метаданные.ПланыОбмена Цикл Сообщить(ТекПланОбмена.Имя + " = " + ПланыОбмена[ТекПланОбмена.Имя].ЭтотУзел().ЭтотУзел); КонецЦикла;
44 — 19.10.18 — 11:07
Выяснил, то ошибка с PRIMARY KEY воспроизводится даже на релизе 3.0.64.54, если включить возможность изменений и поменять режим совместимости 8.3.10 => 8.3.12.
При этом реструктуризации подвергаются объекты:
Новый объект: Хранилище расширений конфигурации (новое поколение данных) Новый объект: Хранилище информации о применении расширений конфигурации к базе данных Новый объект: Хранилище информации о применении расширений конфигурации к базе данных (новое поколение данных) Объект изменен: Хранилище расширений конфигурации Объект изменен: ПланОбмена.АвтономнаяРабота Объект изменен: ПланОбмена.МиграцияПриложений Объект изменен: ПланОбмена.МобильнаяБухгалтерия Объект изменен: ПланОбмена.МобильноеПриложениеПредприниматель Объект изменен: ПланОбмена.Обмен1С_КАМИН_ЗарплатаБухгалтерия30 Объект изменен: ПланОбмена.ОбменЗарплата3Бухгалтерия3 Объект изменен: ПланОбмена.ОбменРозница1Бухгалтерия3 Объект изменен: ПланОбмена.ОбменРозницаБухгалтерияПредприятия30 Объект изменен: ПланОбмена.ОбменСообщениями Объект изменен: ПланОбмена.ОбменСПодключаемымОборудованиемOffline Объект изменен: ПланОбмена.ОбменУправлениеНебольшойФирмойБухгалтерия30 Объект изменен: ПланОбмена.ОбменУправлениеТорговлей103БухгалтерияПредприятия30 Объект изменен: ПланОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия30 Объект изменен: ПланОбмена.ОбновлениеИнформационнойБазы Объект изменен: ПланОбмена.Полный Объект изменен: ПланОбмена.ПоОрганизации Объект изменен: ПланОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат Объект изменен: ПланОбмена.УдалитьОбменРозницаБухгалтерия20 Объект изменен: ПланОбмена.УдалитьОбменРозницаБухгалтерияПредприятия Объект изменен: ПланОбмена.УдалитьОбменУправлениеНебольшойФирмойБухгалтерия20 Объект изменен: ПланОбмена.УдалитьОбменУправлениеТорговлейБухгалтерияКОРП Объект изменен: ПланОбмена.УдалитьОбменУправлениеТорговлейБухгалтерияКОРПФоновый Объект изменен: ПланОбмена.УдалитьОбменУправлениеТорговлейБухгалтерияПредприятия Объект изменен: ПланОбмена.УдалитьПолный Объект изменен: ПланОбмена.УдалитьПоОрганизации Изменена версия структуры информационной базы
Как раз в следующем за релизом 3.0.64.54 в релизе 3.0.65.69 и меняется режим совместимости.
Но так пока что и не ясно как починить базу до обновления, чтобы изменение режима совместимости при накатывании следующего релиза не ломало базу.
45 — 19.10.18 — 11:43
При возврате режима совместимости 8.3.12 => 8.3.10 ТИИ ошибок не выдает… хм.
46 — 19.10.18 — 12:14
(44)
«как починить базу..»
либо исправить исходные данные, приводящие к ошибке.
либо созданные.
первое решается путем расследования тж либо трасс ms sql profiler на предмет , откуда 1с8 берет данные для таблицы с последующим исправлением.
второе — отключением индекса при создании таблицы, удаления дублей, создание индекса.
47 — 21.10.18 — 18:42
Выяснил, что планы обмена изменяются при включении режима совместимости 8.3.11.
Т.е. если включить возможность изменений и просто изменить режим совместимости конфигурации с 8.3.10 на 8.3.11 то баг с ТИИ воспроизводится.
При откате обратно на 8.3.10 бага при ТИИ нет.
Методом последовательного удаления планов обмена из конфигурации выяснил, при снятии с поддержки и удалении только 1 плана обмена УдалитьОбменРозницаБухгалтерия20 баг с ТИИ пропадает.
Т.е. после последующего обновления без этого плана обмена до версии 3.0.65.69 ТИИ базы проходит успешно.
Но проблема обновления в предприятии, описанная в (0), всё еще остается.
48 — 23.10.18 — 23:39
(33) >В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.
Удалил обработкой все непредопределенные элементы всех планов обмена (у которых свойство ЭтотУзел = Ложь) перед обновлением.
Та же ошибка после обновления при обработке данных в предприятии.
49 — 25.10.18 — 16:31
(36) >как вариант попробуй в файловый вариант сконвертить и там обновить
На файловой базе та же ошибка.
ТИИ и chdbfl и до, и после(!) обновления рапортуют, что проблем нет.
При этом, если при появлении ошибки обновления в предприятии открыть обработкой элемент плана обмена Полный и попробовать записать — вываливается в ошибку SDBL.
50 — 31.10.18 — 23:41
Ответ поддержки 1С, цитата:
Проблема возникает, если загрузить dt сформированной более новой версией (в более новом режиме совместимости). Теперь при попытке загрузить такой dt возникает ошибка. Базы, сформированные такой загрузкой ранее некоректны и с ним работать не получится. Исправление на них не влияет. Вам необходимо загрузить базу на том релизе платформы, на котором она была сделана. После этого уже выполнять обновление платформы и обновление. Если это не так, то следует прислать dt вашей базы, сделанные до обновления и на платформе 8.3.10
Помогите перевести этот ответ на русский.
Что надо сделать?
P.S. Я им отправлял .bak-файл MSSQL-бэкапа текущей базы до обновления.
51 — 09.11.18 — 11:44
Новости с полей: «Ваше сообщение зарегистрировано для расследования в отделе разработки <номер>».
52 — 21.11.18 — 11:26
(51) не удалось решить проблему?
53 — 30.11.18 — 16:20
(52) Прошло 3 недели, ответа от отдела разработки 1С нет.
Напомнил им сегодня о себе.
Посмотрим на следующей неделе что ответят.
54 — 19.12.18 — 22:39
Обновляю статус.
Ошибка зарегана 09.11.2018, но в ближайшее время исправлять её никто не собирается.
https://bugboard.v8.1c.ru/error/000048134.html
Как сдавать 4-й квартал без обновлений, хз.
Пока ждал, вышли релизы платформы:
8.3.13.1644 28.11.18
8.3.12.1790 27.11.18
Надо будет попробовать еще на них обновиться.
Имхо, какой-то косяк в платформе, я в этом уверен на 99,9%.
55 — 25.12.18 — 14:58
(50) «Вам необходимо загрузить базу на том релизе платформы, на котором она была сделана. После этого уже выполнять обновление платформы и обновление.»
Писец. Просто нет слов.
«Я им отправлял .bak-файл MSSQL-бэкапа текущей базы до обновления.»
То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.
56 — 25.12.18 — 15:00
(51) А вариант создать пустую базу из шаблона конфигурации и перелить туда все данные через выгрузку-загрузку через XML не рассматривали ? И на новой базе уже проводить обновление.
57 — 25.12.18 — 15:08
(55)[То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.]
ты бредишь и тяжело, не запуская болезнь
58 — 25.12.18 — 15:13
(57) Если ты один айтишник который обслуживает организацию и о твоей идее слить базу куда-то (пусть и с целью починить) никто не узнает то можешь делать что угодно.
Я при приеме на работу подписывал бумаги за сохранность коммерческой тайны. И без письменного разрешения начальника отдела ИТ сливать базу куда-то рискуя уголовкой не собираюсь. И начальник отдела тоже в таком случае захочет прикрыть свой зад бумажкой.
59 — 04.01.19 — 10:12
В общем, исправления бага я так и не дождался, решил проблему обновления в предприятии правкой кода:
ОбщийМодуль.СтандартныеПодсистемыСервер Процедура ЗарегистрироватьОбъектНаВсехУзлах() Если ПланыОбмена[ИмяПланаОбмена].ЭтотУзел() = Неопределено Тогда Возврат; КонецЕсли;
И благополучно обновился до последнего релиза.
ТИИ с исправлением ссылок так и не запускается с ошибкой PRIMARY KEY, но, я думаю, что это ошибка в платформе и когда-нибудь она сама пропадет.
60 — 05.01.19 — 22:23
У этой истории неожиданно появилось продолжение.
При попытке загрузки данных из УТ:
Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы
61 — 05.01.19 — 22:25
(56) Видимо, придётся воспользоваться вашим советом.
Никогда таким не занимался, чтобы перенести все данные из базы в пустую базу.
Подскажите, как это сделать?
62 — 05.01.19 — 22:36
столкнулся с похожей ошибкой при обновлении УТ11. Помог откат на 8.3.10, ТИИ (вроде можно только реструктуризацию, но сделал полностью) и обновление на этой платформе
63 — 09.01.19 — 09:17
(61) Создаете пустую базу из шаблона релиза такого же что и ваша база. Если такого шаблона нет то берете ближайший до этого шаблон и накатываете на него обновления пока не получите базу того же релиза. Если у вас есть изменения в метаданных (как у меня например в справочник контрагентов и договоров добавлены несколько реквизитов) то включаете возможность изменения и добавляете.
Обязательное условие — конфигурация по метаданным должна совпадать. Иначе выгрузка — загрузка через XML не пройдет.
После этого обработкой ВыгрузкаЗагрузкаДанныхXML выгружаете все данные из баз источника. Я делаю «все контатанты, все справочники, все документы с движениями». Плюс надо будет дополнительно перенести независимые регистры сведений (по которым движения без регистраторов).
Если во время выгрузки будет происходить ошибка на каких то объектах то просто снимаете галочку на объектах этого вида.
64 — 09.01.19 — 09:21
(60) (62)
Какую у вас ошибку выдавало ТИИ с реструктуризацией ?
У меня возникали ошибки типа
«В процессе обновления информационной базы произошла критическая ошибка
по причине:
В схеме базы данных отсутствует таблица «Reference39».
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ссылка на таблицу Reference39 недопустима. Нет таблицы или отсутствует RefSelf.»
По структуре БД я определил что Reference39 это Справочник.ДолжностиОрганизаций.
Соответственно выгрузка этого справочника через XML тоже падала и приходилось ее пропускать.
После отката на релиз 8.3.10 эти ошибки ТИИ при реструктуризации ушли ?
65 — 09.01.19 — 09:28
(64) У меня была похожая ошибка типа
Ошибка SDBL:
Ссылка на таблицу недопустима. Нет таблицы или отсутствует RefSelf.
Но ругалось вроде на перечисление. На 8.3.10 прошло без ошибок
66 — 09.01.19 — 12:27
(65) Смотри что получается.
У меня релиз бухгалтерии 2.0.66.65.
Когда запускаю ТИИ под релизом 8.3.13.1513 получаю ошибку
«В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы»
Пробуем запустить ТИИ под релизом 8.3.10.2561.
ТИИ прекрасно проходит.
Обновляем релиз 2.0.66.65 на 2.0.66.67.
Все прекрасно проходит.
Дальше пробую под релизом 8.3.10.2561 перейти на версию 3.0 (обновиться на релиз 3.0.67.54).
Получаю сообщение что для этого нужен релиз не менее 8.3.12
Ставлю его (8.3.12.1714).
Запускаю ТИИ и получаю опять ошибку.
Что можно придумать в этом случае ?
Есть какой-то релиз из линейки 8.3.12 под которым можно провести обновление без ошибок в реструктуризации ?
67 — 09.01.19 — 12:28
(62) Попробуй понижение релиза до 8.3.10.
Реально помогает до какого-то момента.
68 — 09.01.19 — 12:33
(65) Вообще конечно подход 1С что под релизом 8.3.10.2561 ТИИ проходит без ошибок, а под релизом 8.3.13.1513 ТИИ заканчивается ошибкой удивляет.
Данные же одни и те же.
69 — 09.01.19 — 14:16
(65) Попробовал на релизе 8.3.12.1685 который рекомендуется для обновления.
При обновлении в процессе реструктуризации выдает ошибку
«В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Таблица или поле Fld32229 не содержится в разделе FROM (pos=59)»
При простом ТИИ выдает ошибку
«В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы»
При этом под релизом 8.3.10.2561 ТИИ проходит без ошибок.
70 — 17.01.19 — 12:37
Продолжение истории (0), ответ поддержки:
«Приаттаченная база 3.0.64.54 уже содержит проблему, но внешне она не проявлялась. Проблема в том, что в базе 2-е таблицы Const24 и Node24 с одинаковым постфиксом.»
71 — 24.01.19 — 13:50
(70) Вам проблему с базой удалось решить ?
Я у себя решил проблему созданием новой базы из шаблона и переливанием в базу данных.
(71) В общем, поддержка исправила отосланную базу, но инструмент по исправлению (или хотя бы инструкцию) давать отказалась.
Цитирую:
«Восстановить базу пользователь самостоятельно не может, т.к. нужно обновлять также служебные структуры. Мы можем восстановить конкретную проблему, при этом, повторюсь, мы не можем гарантировать что других проблем не будет.»
С учетом того, что они решали проблему 3 месяца, база, которую я им отсылал, стала неактуальной и мне уже нафиг не нужна, тем более, что это не гарантия, что в дальнейшем проблем с ней не будет.
Я решил проблему взятием бэкапа полугодовой давности, в котором точно всё хорошо, и перезаливом данных за полгода из УТ.
Да, возможно бухам придется заново что-то руками подправлять в базе, но это лучше, чем подобный баг вылезет в дальнейшем в исправленной каким-то неведомым способом базе.
Кстати, у меня не взлетели автосгенерированные правила конвертации БП => БП. Справочники еще норм переносило, а на документах вываливалось в ошибку
«Объект = Выдача наличных
ОписаниеОшибки = Ошибка при вызове метода контекста (Записать): Запись не верна! Вид субконто «Статьи движения денежных средств» не доступен для данной записи!»
Не подскажите на будущее как правильно эти правила создавать в конвертации 2.0 или может быть какая-то особенная обработка нужна?
В этой статье описан способ решения ошибки «В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка SDBL: Тип поля Code несовместим с типом литерала STRING». Сразу оговорюсь, что описанный метод больше похож на «танцы с бубнами», но, возможно, кому-нибудь сможет помочь или пригодится что-то из того, что я перепробовал. По крайней мере, поможет натолкнуть на правильную мысль, а также будут подняты другие проблемы, интересные к обсуждению.
В процессе обновления нетиповой ИБ выходит ошибка:
Ошибка возникает на этапе обновления конфигурации базы данных.
Начнём с того, что мне посоветовали:
- Выгрузить/загрузить базу
- Выгрузить/загрузить .сf
- Провести «Тестирование и исправление информационной базы»
Первые 2 пункта мне не помогли, а ТиИ именно на проверке логической целостности вываливается со следующей ошибкой:
Причину этой ошибки выявить не удалось, как и загрузить в файловую версию, т.к. 2 таблицы (
AccumRg27945 — это РегистрНакопления.ЗатратыНаВыпускПродукцииНалоговыйУчет
AccumRg27891 -РегистрНакопления.ЗатратыНаВыпускПродукцииБухгалтерскийУчет) превышают 4 гига.
Буду рад услышать в комментариях ваше мнение по решению этой, уже другой ошибки. Конечно, не очень хотелось заниматься сворачиваем этих регистров ради выгрузки в файловую версию ради проведения ТиИ, а просто заставить ТиИ работать на клиент-серверной версии. А всё началось просто с ошибки обновления. Вернемся к ней…
Предположив, что ошибка обновления выходит из-за конкретного документа, справочника или другого объекта, проводим обновления методом исключения, т.е. при сравненииобъединении без фильтрации по дважды измененным свойствам снимаем галочки с половины объектов. Если обновление проходит успешно, значит, ошибка в другой половине, если с ошибкой, значит, в этой половине. Затем эту половину снова делим на 2 и т.д.
В результате недельного труда, виновником оказался Справочник.ВидыДокументов, он же «Виды подтверждающих документов».
Немного об этом справочнике: «Виды подтверждающих документов» — предназначен для хранения типов документов, которые участвуют в системе электронного обмена подтверждающими документами с уполномоченным банком, что позволяет банку ускорить процесс проверки платежных поручений.
Типовой справочник, который появился в предыдущем обновлении месяц-два назад. Самое интересное что он в текущей базе не используется, потому что организация не занимается государственными контрактами и в настройке параметров учета эта функциональность отключена. Всё, что там есть — это предопределенные элементы.
В моей базе справочник типовой, но при сравнении/объединении показывает что будто бы изменили динамический список в форме списка справочника.
Получается, если просто снять галочку с этого справочника, т.е. не обновлять справочник, то обновление пройдёт успешно. Но помнить о том, что нужно снимать галочку каждый раз, когда поставщик вносит изменения, не лучшее решение.
Делаем запрос и ищем странности в этом справочнике:
Из странностей видим только то, что в коде одного из элементов куча пробелов, проверяем в основной конфигурации и старой конфигурации поставщика — там тоже эти лишние пробелы, а в новой конфигурации поставщика нет пробелов.
Далее смотрим, какие же изменения вносит поставщик:
Видим, что поставщик уменьшил длину кода с 9 до 3, но самое интересное тут то, что поставщик изменил тип кода со «строки» на «число». Видимо, именно об этом и говорит ошибка «Тип поля Code несовместим с типом литерала STRING». Получается, платформа меняет тип кода, а потом не может записать строковые коды предопреденных элементов в числовое поле. Или что там в какой последовательности, я точно не знаю.
Проверяем. В конфигураторе включаем возможность редактирования справочника, переводим тип кода в числовой тип. Обновляем конфигурацию БД. Тип кода сменился без ошибок, а значит, коды предопределенных элементов преобразовались без ошибок.
Теперь накатываем обновление поставщика, видим, что тип кода и его длина не участвуют в обновлении, потому что совпадают, зато участвуют предопреденные элементы.
Обновление прошло успешно! Теперь осталось дождаться выходных и накатить это на рабочую базу.
И последнее, о чем следует упомянуть, это то, что все эти действия выполнялись на платформе 1С:Предприятие 8.3 (8.3.5.1248), при переходе с релиза УПП 1.3.73.2 на 1.3.74.1
Обычно ошибка SDBL происходит при сохранении и обновлении конфигураций в момент реструктуризации базы данных, а также во время работы обменов данными.
Окно с данной ошибкой 1С имеет дополнительное содержание. Типичные сообщения:
- Ожидается выражение (pos = ).
- Выход за пределы размерности.
- Поле таблицы не может принимать значение NULL.
- Ошибка при полнотекстовом индексировании.
- Попытка вставки значения недопустимого типа.
- Поле определено неоднозначно.
- Пропущена точка с запятой.
- В схеме базы данных нет таблицы с именем…
Исправление ошибки SDBL
Большая часть способов исправления связана с восстановлением нормальной работы Информационной Базы. Но иногда описанными способами решить проблему не получается, поэтому помните о самом лучшем, универсальном способе — регулярном резервном копировании.
Перезагрузка сервера 1С и SQL-сервера
Самый простой способ, при условии, что на текущий момент в базе никто не работает.
Зайдите на сервер и выключите следующие службы:
- «Агент сервера 1С»,
- «SQL Server»,
- «Агент SQL Сервера».
А затем запустите их обратно.
Очистка кэша на сервере и клиента, где проявилась ошибка
В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С.
Как правило кэш расположен по адресу:
- «%userprofile%Local SettingsApplication Data1C1Cv8» и «%userprofile%Application Data1C1Cv8» для Windows XP,
- «%userprofile%AppDataRoaming1C1Cv8» и «%userprofile%AppDataLocal1C1Cv8» для Windows 7 и выше.
Перейдите в данный каталог и удалить все папки с генерированными именами вида « dg7c8re4-b89r…». При удалении будьте внимательны — в этой директории может присутствовать индекс полнотекстового поиска 1С, а также журналы регистрации, их удалять не нужно.
Перезаливка базы из DT-файла
Иногда помогает, казалось бы, парадоксальный способ — выгрузка базы данных в файл формата DT, а затем загрузка его обратно.
Войдите в режим «Конфигуратор», выберите пункт меню «Администрирование» > «Выгрузить информационную базу» и выберите каталог для сохранения файла.
Затем через аналогично через меню «Администрирование» > «Загрузить информационную базу» загрузите его обратно.
Тестирование и исправление Информационной базы
Для тестирование и исправление Информационной базы: войдите в «Конфигуратор», выберите пункт меню «Администрирование» > «Тестирование и исправление».
В случаях, когда невозможно запустить конфигуратор, воспользуйтесь утилитой chdbfl.exe. Это упрощенная программа-аналог тестирования базы, функции, которая запускается в режиме конфигуратора. Расположена она в папке «bin» установленной технологической платформы, например, C:Program Files (x86)1cv88.3…binchdbfl.exe.
Пользоваться ей просто — указываете путь к файлу базы данных и ставите опцию, нужно ли сразу исправлять обнаруженные ошибки. Если нет — утилита только продиагностирует ИБ.
Обновление платформы до новой версии
В данном случае всё достаточно просто. Скачивает с сайта поддержки 1С дистрибутив свежей версии платформы, распаковываем и запускаем инсталятор setup.exe.
Очистка таблиц базы данных
В крайнем случае можно попробовать удалить таблицы БД, связанные с ошибкой — «dbo._ConfigChngR» и «dbo._ConfigChngR_ExtProps».
Производится это через менеджер SQL-скриптом вида:
use имя_базы_данных
delete from dbo ._ ConfigChngR
delete from dbo ._ ConfigChngR _ ExtProps
Помните, прямые SQL-запросы лучше доверить профессионалу, умеющему работать с SQL.
to continue to Google Sites
Not your computer? Use Guest mode to sign in privately. Learn more