Ошибка sdbl тип поля несовместим с типом литерала undefined

Удалить пустую запись в ТЧ справочника.

Я

   фпк1сл

24.12.18 — 19:28

Имеем справочник «Организации» с одни элементом. Делаем запрос «Выбрать * из Справочник.Организации.КонтактнаяИнформация» — в результате имеем 5 строчек, относящихся к нашей организации и одну строчку абсолютно пустую, не привязанную ни к какой организации(строчка ссылается не на битую ссылку, а именно на пустую ссылку справочника Организации). ТИС с логической целостностью выдает «Ошибка SDBL: Тип поля FLD3891 несовместим с типом литерала UNDEFINED», база файловая, утилита chdbfl не находит ошибок. Поиск и замена значений тоже не помогла.

Как удалить эту пустую запись, может кто сталкивался?

   ГдеСобакаЗарыта

1 — 24.12.18 — 19:34

А что если пометить ее на удаление, а потом удалить?

   Mort

2 — 24.12.18 — 19:34

Создать элемент с таким уидом и удалить нормально.

   Mort

3 — 24.12.18 — 19:35

А блин, пустая. Ну тада запросом к бд

   Mort

4 — 24.12.18 — 19:36

А блин, файловая )

   ДенисЧ

5 — 24.12.18 — 19:40

Отобрать запросом эту запись, пометить на удаление, удалить помеченные

   фпк1сл

6 — 24.12.18 — 19:44

Если сделать просто тестирование, то выдается сообщение

«Проверка логической целостности. Справочники. Организации. Табличная часть имеет записи, не относящиеся ни к одной записи главной таблицы. Количество — 1

»

Запись — это строка тч, которая подчинена элементу справочника организации. Чтобы её удалить, насколько я понимаю, мне надо получить объект, и после этого я смогу удалить пустую строчку, но в том то и проблема, что объекта нет.

   фпк1сл

7 — 24.12.18 — 19:44

Выгрузка dt и загрузка в новую базу тоже не дало результата.

   unregistered

8 — 24.12.18 — 19:48

Если ТИИ не исправляет такую ошибку, то только правка таблиц напрямую. Для клиент-серверных баз в соответствующей СУБД, для файловых — даже не знаю — умеют ли разного рода народные утилиты работать с таблицами или нет. Файловую можно попробовать загрузить в клиент-серверную и там грохнуть кривую запись средствами SQL.

   Chameleon1980

naïve

9 — 24.12.18 — 19:48

Tool1CD

   фпк1сл

10 — 24.12.18 — 19:51

Спасибо за наводки, буду копать в этом направлении.

   Сияющий в темноте

11 — 24.12.18 — 19:53

   фпк1сл

12 — 24.12.18 — 19:54

Проблема в том, что ссылка не битая. Просто строка тч ссылается на пустой элемент справочника.

   youalex

13 — 24.12.18 — 20:04

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

   youalex

14 — 24.12.18 — 20:04

ну или через скуль.

   МихаилМ

15 — 24.12.18 — 20:58

не надо скуль и тул сиди. создайте запись справочника с гуидом как у не привязанной строки тч. строка

«привяжется» , удалите запись.

   youalex

16 — 24.12.18 — 21:08

(15) не прокатит, ибо

(0) строчка ссылается не на битую ссылку, а именно на пустую ссылку справочника Организации

   Chameleon1980

naïve

17 — 24.12.18 — 21:14

(15)+(16) оттого и тулсиди

ТС не сиди — бери тулсиди

   Chameleon1980

naïve

18 — 24.12.18 — 21:15

создать подлежащий удалению владелец

прописать его как владельца для записей ТЧ

удалить все к ..рам

   Chameleon1980

naïve

19 — 24.12.18 — 21:20

   Chameleon1980

naïve

20 — 24.12.18 — 21:23

ой. или тут ТЧ справочника?

да один хрен.

берем тулсиди

счас глянем

   Chameleon1980

naïve

21 — 24.12.18 — 21:25

   фпк1сл

22 — 25.12.18 — 10:40

Всем спасибо, загрузили базу на SQL, и там уже грохнули пустую строчку!

круто

ну можно было и не в скуле

Содержание:

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.

Специалист компании «Кодерлайн»

Айдар Фархутдинов

В процессе обновления нетиповой ИБ выходит ошибка:

Ошибка возникает на этапе обновления конфигурации базы данных.

Начнём с того, что мне посоветовали:

1. Выгрузить/загрузить базу
2. Выгрузить/загрузить .сf
3. Провести «Тестирование и исправление информационной базы»

Первые 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