Ошибка sdbl поле fld в from

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

Содержания могут быть следующими:

Ошибка SDBL: Ожидается CAST, идентификатор или константа (pos=32), Ошибка при полнотекстовом индексировании

Ошибка SDBL: Поле Fld1318 таблицы Document11 не может принимать значение NULL (pos=15)

Ошибка SDBL: Выход за пределы размерности результата — данный сбой возникает в конфигураторе при обновлении конфигурации на этапе реструктуризации базы данных. Последнее что можно увидеть в строке состояния: …» Выход за пределы размерности результата

Ошибка SDBL: Попытка быстрой вставки значения недопустимого типа (pos = 23)

Тексты ошибок могут отличаться и это только одни из множества вариантов.

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

  1. Перезагрузка сервера 1С, SQL — сервера;
  2. Очистить кэш (cache) пользователя и сервера 1С;
  3. Выполнить процедуру тестирования и исправления (Конфигуратор-Администрирование-Тестирование и исправление…);
  4. Резервное копирование и загрузку файла 8.dt обратно в эту же базу;
  5. Обновить платформу до последнего релиза.

Рекомендуем не проводить экспериментов в поисках решения проблемы. Мы готовы решить эту ситуацию быстро и не дорого!

Если ничего из этих действий не привело к результату, то, рекомендуем попробовать очистить таблицы _ConfigChngR и _ConfigChngR_ExtProps, через менеджер SQL простым скрипто:

use Имя_БД 
delete from dbo._ConfigChngR 
delete from dbo._ConfigChngR_ExtProps

 

 Также, в 1С встречаются и другие трудности. Подробнее о распространенных ошибках можно почитать тут.

Содержание:

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.

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

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

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

Окно с данной ошибкой 1С имеет дополнительное содержание. Типичные сообщения:

  • Ожидается выражение (pos = ).
  • Выход за пределы размерности.
  • Поле таблицы не может принимать значение NULL.
  • Ошибка при полнотекстовом индексировании.
  • Попытка вставки значения недопустимого типа.
  • Поле определено неоднозначно.
  • Пропущена точка с запятой.
  • В схеме базы данных нет таблицы с именем…

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

Перезагрузка сервера 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.

Исправление ошибки SDBL в 1С 8.3


Современные версии 1С имеют многоуровневые код, который порой становится причиной разного рода ошибок. Они доставляют неудобства не только обычным пользователям конфигураций, но и сотрудникам служб администрирования. Большинство сбоев можно устранить без особых проблем, но встречаются и такие, что требуют от администраторов консолидации всех знаний и умений. Рассмотрим одну из самых «популярных» ошибок, которую в  принято обозначать как «Ошибка SDBL».

Закажите звонок на сайте, чтобы получить бесплатный анализ вашей базы данных на наличие ошибок. 



Как она проявляется?


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

  1. Ошибка при полнотекстовом индексировании;

  2. Недопустимый тип вставки значения;

  3. Табличные поля не принимают значение NULL;

  4. Происходит пропуск точки с запятой;

  5. Вышли за пределы размерности;

  6. Поле определено неоднозначно.

SDBL Выход за пределы размерности результата.JPG




Это лишь небольшой перечень сообщений, которые отображаются при возникновении рассматриваемой проблемы.


Как исправить ошибку SDBL в программах 1С?

Перед любыми действиями обязательно сделайте резервную копию базы данных.

Существует алгоритм простых действий, позволяющий устранить сбой без особых усилий:

1. Провести очистку кэша на рабочем месте пользователя и на сервере, где возник сбой. Для этого следует выйти из программы, выбрать и удалить папки, в названии которых есть примерно такой набор символов: «bd5c8ea4-b65f-4c23-a9c8-2dccfb0b15fa» (папка «Application Data»).

2. Перезагрузить сервер, где установлены приложения 1С. Как вариант — включить и выключить все связанные сервисы SQL и его агента. Процесс проходит так: зайти на сервер, найти службу «Агент сервера 1С» и остановить ее через контекстное меню. Подобное проделать со службами «SQL Server» и «Агент SQL Сервера» на сервере SQL. После чего активировать все в обратном порядке.

3. В конфигураторе внедрено «Тестирование и исправление ИБ». Суть такова: выбрать поврежденную информационную базу, зайти в «Администрирование», далее «Тестирование и исправление…» и активировать процесс.

4. Еще один способ: выгрузить базу в файл формата DT, затем загрузить его в ту же базу. Т.е. в режиме конфигуратора открыть меню «Администрирование». Активировать функцию «Выгрузить информационную базу…» и «Загрузить информационную базу…».

5. Если есть «свежая» резервная копия, то загрузить ее. Кстати, резервные копии рекомендуем делать регулярно, а в случае, когда планируются работы по изменению базы, следует сформировать их еще раз. Есть два основных способа резервирования: через SQL MS или конфигуратор с помощью выгрузки файла в формате dt.

6. Еще один достаточно действенный способ — обновить платформу через сайт ИТС до самой актуальной версии на сегодняшний день. Для этого выгрузить с портала ИТС «свежую» платформу и установить ее на сервер и на клиентские рабочие места.



Возможно, возникнет ситуация, когда все выше названные варианты устранения проблемы не помогут. В таком случае есть еще один надежный способ. В клиент-серверной базе 1С необходимо очистить таблицы _ConfigChngR_ExtProps и _ConfigChngR.


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

Отзывы о компании

  • Сивелькина С. В.

    ПАО «НИКО-БАНК» выражает свою благодарность за оперативную и грамотную работу.
    В условиях постоянно меняющегося законодательства Банк заинтересован иметь полную и актуальную номативную базу. Это обеспечивается использованием Банком справочно-нормативной системы «Гарант». 

    Безусловным плюсом в работе компании «МастерСофт» является быстрое реагирование сотрудников при предоставлении документов по запросу Банка, принятых до обновления справочно-правовой системы.

  • Мордвинцев С. П.

    Коллектив компании «АЭРОПОРТ ОРЕНБУРГ» выражает благодарность за взаимовыгодное сотрудничество с МастерСофт-ИТ. Оперативная поставка антивирусных программ Dr. Web обеспечила надежную защиту нашей компьтерной сети.

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

  • Ряховская Н. А.

    ООО «Орский Вагонный Завод» выражает искреннюю благодраность за качество обслуживания вашими специалистами. Консультации и поставка антивирусов всегда проходят оперативно и на высоком профессиональном уровне.
    Уверены, что и в дальнейшем наше сотрудничество на взаимовыгодных условиях продолжится.

  • Кетерер Т. М.

    Главный бухгалтер муниципального бюджетного учреждения дополнительного образования «Дворец творчества детей и молодёжи» Кетерер Татьяна Михайловна выражает благодарность специалистам МастерСофт:
    «Я хотела бы объявить благодарность вашим сотрудникам. Работает с нами по программе «1С: Бухгалтерия бюджетного учреждения 8» непосредственно Шевлягина Юлия.

    Так же огромная благодарность за отзывчивость, терпение и квалифицированную, своевременную помощь Набокиной Олесе и Ерёменко Татьяне (они нас сопровождают по программе «Зарплата и Кадры»).


    Им очень с нами тяжело, но они терпеливо продолжают сотрудничать. С вами очень надёжно. Конечно же наши ошибки есть и без вас мы бы вообще о них не знали и в суде, наверное, судились бы. А сейчас мы решаем вопросы…».

Специфика современных версий учетных программ обуславливается использованием многоуровневого кода. Логично, что чем сложнее структура — тем выше вероятность возникновения внеплановых ситуаций, с которыми приходится сталкиваться рядовым пользователям конфигурации. В отдельных случаях даже сотрудники администрирующих служб предприятия не всегда способны сразу определить исходную причину появления неполадок, поэтому работа по устранению неудобств может занять немало времени. Одной из наиболее часто встречающихся проблем является классическая ошибка SDBL 1С, источники и способы устранения которой мы и рассмотрим в сегодняшнем обзоре.

многоуровневый код сайта

Общее представление

Взаимодействуя с учетной программой, пользователи выполняют различные операции, каждая из которых, так или иначе, формирует запрос к базе данных. Создание нового документа, интеграция библиотеки, плановое обновление — во время любого из процессов есть вероятность получить в ответ уведомление от системы, свидетельствующее о том, что одна из логических цепочек была нарушена. Распространенный вариант — когда на экране появляется сообщение об ошибке SDBL 1С ожидается выражение (pos = 6) (а также 15, 57, 198, 250, 469, или любой другой номерной идентификатор).

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

структура базы данных

Впрочем, сильно переживать не стоит. Появление ошибки SDBL 1С еще не значит, что структура базы данных предприятия разрушена полностью — в большинстве случаев исправить проблему можно при помощи стандартного набора способов, реализовать которые под силу даже начинающим пользователям.

Причины возникновения

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

Если говорить об уже упомянутой ранее ошибке SDBL 1С «ожидается выражение (pos = 144)» (или 48, 153, 13 — не столь принципиально), то в этом случае ключевым обстоятельством становится повреждение базы данных, обусловленное нарушением системных логических циклов. К числу распространенных причин возникновения, отмечаемых специалистами, относят не только применение устаревшей конфигурации или платформы, но также и проблемы, связанные с серверным кешем. Кроме того, всегда существует вероятность случайного запуска с некорректной учетной записи, не обладающей достаточным набором прав.

ошибка sdbl pos 6

Чаще всего системные ошибки происходят в процессе очередного обновления БД, а также при обращении к ней — через запрос на добавление документов, во время тестовой проверки логической целостности, или же в иных ситуациях. Критической проблемой при установке расширений может стать и «некорректное использование LOCAL/GLOBAL в SET GENERATION», не позволяющее полноценно сохранить базу даже после выборочного удаления. Стоит отметить, что стандартное решение в виде перезагрузки программы обычно не помогает, поэтому для восстановления работоспособности придется воспользоваться альтернативными методиками.

Какие сообщения возникают

архивация бд

Уведомление о технических неполадках отражает специфику возникшей проблемы, и может появиться как во время обновления конфигурации, так и в процессе работы с обменом данных. Как правило, текст в информационном окне раскрывает специфику возникшей ошибки SDBL 1С: «не является именем поля», «ожидается идентификатор» или «выход за пределы размерности результата 1C», и т. д.

Встречаются и вспомогательные приписки, причем их количество зависит от конкретной неточности, допущенной в ходе сборки и настройки обновленного расширения:

  • предпринята попытка ввести неприемлемый тип значения «NULL»;

  • пропущена точка с запятой;

  • нарушение индексирования с полным текстом;

  • неоднозначное определение некоторого поля;

  • отсутствует выражение (pos =) — с различными числовыми идентификаторами в скобках.

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

уведомление о технических неполадках

Готовые решения для всех направлений

Склады

Ускорь работу сотрудников склада при помощи мобильной автоматизации. Навсегда устраните ошибки при приёмке, отгрузке, инвентаризации и перемещении товара.

Узнать больше

Магазины

Мобильность, точность и скорость пересчёта товара в торговом зале и на складе, позволят вам не потерять дни продаж во время проведения инвентаризации и при приёмке товара.

Узнать больше

Маркировка

Обязательная маркировка товаров — это возможность для каждой организации на 100% исключить приёмку на свой склад контрафактного товара и отследить цепочку поставок от производителя.

Узнать больше

E-commerce

Скорость, точность приёмки и отгрузки товаров на складе — краеугольный камень в E-commerce бизнесе. Начни использовать современные, более эффективные мобильные инструменты.

Узнать больше

Учреждения

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

Узнать больше

Производство

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

Узнать больше

RFID

Первое в России готовое решение для учёта товара по RFID-меткам на каждом из этапов цепочки поставок.

Узнать больше

ЕГАИС

Исключи ошибки сопоставления и считывания акцизных марок алкогольной продукции при помощи мобильных инструментов учёта.

Узнать больше

Сертификация

Получение сертифицированного статуса партнёра «Клеверенс» позволит вашей компании выйти на новый уровень решения задач на предприятиях ваших клиентов..

Узнать больше

Инвентаризация

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

Узнать больше

Показать все решения по автоматизации

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

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

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

проблемы с базой данных

Практически любая ошибка SDBL 1С — «недопустимый символ (pos = 40)», «пропущена точка с запятой», или «ожидается имя таблицы 21», может быть устранена путем выполнения несложного набора действий. Перечень доступных вариантов выглядит следующим образом:

  1. Удаление кэшированных данных — как на пользовательском рабочем месте, так и на основном сервере, где произошел технический сбой. Для реализации процедуры очистки кэша достаточно закрыть учетную программу, открыть «Проводник», найти, выбрать и удалить набор папок из раздела «Application Data». Отличить нужные элементы проще всего по названию, которое выглядит как хаотичный набор символов — например, «ac5c8bm4-y65k-4s23-a9g8-2dcttp0b15da».

  2. Использование функционала Конфигуратора, позволяющего провести тестирование и исправление информационной базы. В этом случае необходимо найти поврежденную ИБ, выбрать ее и перейти в раздел «Администрирование», после чего активировать встроенную функцию для теста и корректировки ошибок.

  3. Перезагрузка сервера, на котором расположены программные приложения системы 1С. Самый простой вариант — включение и выключение всех взаимосвязанных SQL-сервисов, включая агент. Для выполнения задачи нужно зайти на нужный серверный источник, выделить агентскую службу, вызвать контекстное меню и остановить процесс. Аналогичные действия повторяем на SQL со служебными процедурами Server и Agent. Повторная активация осуществляется в обратном порядке.

  4. Выгрузка БД в отдельный DT-файл с последующей повторной «заливкой». По сути, метод напоминает стандартную перезагрузку системы — структура записывается в файловом формате, что позволяет упорядочить проблемные разделы. Для выполнения процедуры достаточно открыть меню управления учетной программой, найти в категории «Администрирование» функцию «Выгрузить информационную базу», и после ее завершения выбрать опцию «Загрузить ИБ», используя сформированный файл.

  5. Откат к последней резервной копии. Один из самых простых и доступных вариантов — конечно, в том случае, если архивирование данных проводится на регулярной основе, а не только перед закрытием периодов. Вообще, решение записывать текущее состояние перед каждым внесением изменений может избавить от большинства проблем, связанных с техническими сбоями. Даже если вы столкнетесь с уведомлением о том, что «ожидается имя поля», или получите ошибку «таблица 1С inforg не создана в новом поколении», источник которой не всегда понятен даже опытным пользователям — загрузка последней копии просто вернет систему к исходному состоянию. Для резервирования допускается использование как SQL MS, так и Конфигуратора учетной программы — через последовательную выгрузку файлов в уже упомянутом DT формате.

  6. Обновление платформы через сайт информационно-технологического сопровождения разработчиков, доступный всем лицензированным пользователям продукта. Функционал портала ИТС позволяет установить последнюю редакцию, актуальную на момент обращения, инсталляция которой производится как на основной сервер, так и на рабочие места клиента.

Как правило, один из перечисленных методов позволяет добиться желаемого результата, устраняя проблему в работе учетной системы. В ситуациях, когда применить готовое решение так и не удалось, есть резервный вариант, отличающийся высокой вероятностью успешного исхода. Очистка в менеджере SQL 1С таблиц ConfigChngR и ExtProps, что за последние годы стало уже привычным способом восстановления для большинства специалистов, осуществляется стандартной командой Delete.

На что еще обратить внимание при устранении ошибок SDBL, и как реализовать рассмотренные методы? Сейчас разберемся.

Права доступа

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

Перезагрузка серверов 1С и SQL

Это один из простейших методов восстановления, единственным обязательным условием, для применения которого является выход всех пользователей из базы. Убедившись, что доступ открыт, зайдите на сервер и последовательно выключите агент программы Server и SQL-agent, после чего запустите их в обратном порядке.

Удаление кэшированных данных

ошибка sdbl 1c

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

Перечень факторов, обуславливающих нарушение логических циклов, весьма обширен, и охватывает не только динамические обновления системной структуры, но и технические сбои программного или аппаратного характера. В некоторых случаях для устранения ошибки SDBL 1С «ожидается имя поля/таблицы (pos = 21, 45, 48…)» достаточно почистить кэш, сохраненный на сервере, либо на рабочем месте пользователя.

Стандартный путь к месту хранения кэшированных данных выглядит следующим образом:

  • «%userprofile%AppDataRoaming1C1Cv8» и «%userprofile%AppDataLocal1C1Cv8» — для операционных систем начиная с Windows 7.

  • «%userprofile%Local SettingsApplication Data1C1Cv8» и «%userprofile%Application Data1C1Cv8» — для тех, кто все еще продолжает работать на ХР.

Откройте каталог, расположенный по указанному адресу, выделите и удалите все хранящиеся в нем папки, имя которых представляет собой сгенерированный автоматически набор цифр и букв (вроде «abg7n8ty4-brt9r893-am…»). Стоит отметить, что во время чистки кэша нужно быть особенно внимательными, поскольку в директории также могут находиться поисковый индекс и журналы регистрации 1С, которые не требуют удаления.

Загрузка DT-файла

устранение проблем базы 1с

Этот метод может показаться немного странным, поскольку фактически не предполагает внесения каких-либо корректировок в основную структуру данных. Однако в действительности выгрузка БД в отдельный файл, сохраняемый в формате DT, с последующим обращением к ней же, нередко позволяет восстановить нормальную работу программы. Алгоритм достаточно прост — в режиме Конфигуратора нужно выбрать раздел «Администрирование», использовать опцию «Выгрузить ИБ» (указав каталог для сохранения), после чего повторно залить сформированную базу обратно в систему.

Тестирование и исправление

Еще одна удобная функция, доступная в режиме корректировки конфигурации — встроенный инструментарий, предназначенный для теста и внесения коррективов. В отдельных ситуациях может возникнуть проблема с запуском Конфигуратора — вместо этого можно воспользоваться специальной утилитой chdbfl.exe, представляющей собой упрощенный программный аналог с идентичным функционалом. Приложение находится в каталоге «bin», поэтому найти его не составляет особого труда — как через стандартный путь «C:Program Files (x86)1cv88.3bin», так и через опцию поиска, предлагаемую операционной системой.

сбой при обновлении конфигурации

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

Обновление платформы

Еще одно простое решение, предусматривающее использование сайта технической поддержки разработчиков 1С. Скачайте дистрибутив актуального релиза, распакуйте архив и активируйте инсталлятор setup.exe — система обновится автоматически.

Очистка таблиц базы данных

Если ни один из вышеперечисленных способов не дал желаемого результата — остается вариант с удалением табличных значений БД, вызывающих появление ошибки, расположенных в каталогах ConfigChngR и ExtProps. Для этого применяется скрипт менеджера SQL, с указанием информационного раздела и командой delete from. В этом случае лучше всего обратиться к профильному специалисту, поскольку некорректное восстановление может привести к более серьезным последствиям.

Заключение

Автоматизация учетных процессов — важный аспект, позволяющий оптимизировать работу компании. Ошибки SDBL 1С встречаются достаточно часто, поэтому стоит заранее позаботиться об оперативном устранении возможных проблем. Мобильные решения, предлагаемые компанией «Клеверенс», гарантируют квалифицированную поддержку, а также помогут решить задачи, связанные с учетом данных на предприятии.

Количество показов: 7300

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

Содержания могут быть следующими:

Ошибка SDBL: Ожидается CAST, идентификатор или константа (pos=32), Ошибка при полнотекстовом индексировании

Ошибка SDBL: Поле Fld1318 таблицы Document11 не может принимать значение NULL (pos=15)

Ошибка SDBL: Выход за пределы размерности результата — данный сбой возникает в конфигураторе при обновлении конфигурации на этапе реструктуризации базы данных. Последнее что можно увидеть в строке состояния: …» Выход за пределы размерности результата

Ошибка SDBL: Попытка быстрой вставки значения недопустимого типа (pos = 23)

Тексты ошибок могут отличаться и это только одни из множества вариантов.

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

  1. Перезагрузка сервера 1С, SQL — сервера;
  2. Очистить кэш (cache) пользователя и сервера 1С;
  3. Выполнить процедуру тестирования и исправления (Конфигуратор-Администрирование-Тестирование и исправление…);
  4. Резервное копирование и загрузку файла 8.dt обратно в эту же базу;
  5. Обновить платформу до последнего релиза.

Рекомендуем не проводить экспериментов в поисках решения проблемы. Мы готовы решить эту ситуацию быстро и не дорого!

Если ничего из этих действий не привело к результату, то, рекомендуем попробовать очистить таблицы _ConfigChngR и _ConfigChngR_ExtProps, через менеджер SQL простым скрипто:

use Имя_БД 
delete from dbo._ConfigChngR 
delete from dbo._ConfigChngR_ExtProps

 

 Также, в 1С встречаются и другие трудности. Подробнее о распространенных ошибках можно почитать тут.

Содержание:

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С (открытии документа, установки библиотеки, обновлении БД и других смежных операций) пользователь может столкнуться с сообщением «Ошибка SDBL: Таблица или поле configversion не содержится в разделе FROM».  Обычно это связано с техническим сбоем в работе 1С, и лечиться рядом способов, описанных нами ниже. В данном материале мы разберём, в чём суть данной дисфункции, и как её исправить.

Скриншот ошибки configversion

Содержание

  1. Почему возникает ошибка
  2. Убедитесь в наличии достаточных прав для запуска системы
  3. Обновите вашу конфигурацию (платформу) 1С
  4. Используйте инструмент «Тестирование и исправление».
  5. Выгрузите и загрузите файл Dt
  6. Перезагрузите сервер 1С
  7. Очистите кэш сервера 1С
  8. Очистите таблицы в менеджере SQL
  9. Заключение

Почему возникает ошибка

Рассматривая нами ошибка SDBL является представительницей целого пула схожих ошибок с текстом «Таблица или поле не содержится в разделе FROM». Такие ошибки обычно связаны с повреждением базы данных из-за различных причин, самой распространённой из которых является технический сбой в работе системы 1С.

Среди других причин ошибки SDBL также выделяют:

  • Использование устаревшей конфигурации или платформы 1С;
  • Проблемы с кешом сервера 1С;
  • Запуск системы с недостаточными правами (к примеру, от имени учётной записи гостя вместо администратора) и другие причины.

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

Давайте рассмотрим, как исправить ошибку SDBL: Таблица или поле в вашей системе 1С.

Читайте также: как исправить ошибку неверного формата хранилища данных в 1С.

Убедитесь в наличии достаточных прав для запуска системы

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

Обновите вашу конфигурацию (платформу) 1С

Также проверьте, пользуетесь ли вы самой свежей версией платформы (конфигурации) 1С. При необходимости обновите вашу систему до самой свежей версии продукта. Это может помочь устранить ошибку SDBL с полем configversion в 1С.

Используйте инструмент «Тестирование и исправление».

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

Меню администрирования в 1С

Исправьте ошибки в ваших базах данных

Выгрузите и загрузите файл Dt

Хорошие результаты в избавление от ошибки «поле configversion не содержится в разделе FROM» показал способ, состоящий в выгрузке и последующей загрузке файла Dt (архивной копии базы 1С). Для выгрузки базы зайдите в Конфигуратор, там выберите «Администрирование» , где нажмите на «Выгрузить информационную базу».

Опция Выгрузить информационную базу в 1С

Для загрузки выгруженной ранее базы в систему вновь запустите «Конфигуратор», перейдите на вкладку «Администрирование», и в ней активируйте опцию «Загрузить информационную базу». Это может помочь избавиться от ошибки «SDBL: Таблица или поле configversion»

Опция загрузки базы в 1С

Это интересно: ошибка 2147221164 «Класс не зарегистрирован» в 1С — как решить.

Перезагрузите сервер 1С

Для устранения дисфункции рекомендуем перезагрузить сервер 1С. Перезагрузка указанного сервера обычно выполняется автоматически на протяжении 3-5 минут при условии отсутствия у сервера подключенных пользователей.

Очистите кэш сервера 1С

В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С. Обычно кэш расположен по адресу:

c:ProgramFiles1cv8srvInforeg_1541

Туда нужно перейти и удалить папки с генерированными именами. Учтите, что кроме кэша в данной папке могут находиться журналы регистрации, а также индекс полнотекстового поиска 1С.

Файлы кэша в директории

Очистите таблицы в менеджере SQL

Также можно попробовать выполнить очистку таблиц таблицы _ConfigChngR и _ConfigChngR_ExtProps с помощью команды delete.

Вас заинтересует: как устранить дисфункцию «Невозможно создание объекта сервером программирования объектов».

Заключение

В нашем материале мы разобрали причины ошибки «SDBL: Таблица или поле configversion не содержится в разделе FROM» и способы её устранения. Среди всех перечисленных альтернатив хорошую эффективность показал способ с выгрузкой файлов базы данных (файл с расширением Dt), с последующей их повторной загрузкой. Обычно после этого ошибка бывает устранена, и вы сможете пользоваться нормальным функционалом системы 1С.

  

jk3

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

поняли. а что хотели? предупредть ?

  

jk3

2 — 11.10.18 — 17:32

(1) Что делать чтобы обновилось без этой ошибки?

Всё делал на тестовой базе.

Рабочую, естественно, оставил пока на релизе 3.0.64.54.

Но рано или поздно придётся обновлять, а тут такая Ж.

Может быть кто-то уже столкнулся с тем же самым и смог победить.

  

Amra

3 — 11.10.18 — 17:33

Более свежий релиз платформы попробуй, из 12ых

  

dka80

4 — 11.10.18 — 17:34

(2) вы не первый, кто жалуется на ошибки при переходе на этот релиз. Поэтому лучше переждать

  

jk3

5 — 11.10.18 — 17:39

Да, забыл уточнить, что никакого РИБ в помине нет. Это одиночная база.

  

jk3

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

  

VladZ

7 — 11.10.18 — 17:41

(0) Последнюю платформу (8.3.13) не пробовал ставить?

  

jk3

8 — 11.10.18 — 17:46

(7) Я таким экстримом не занимаюсь))

Обновляю платформу только по надобности и не на самый последний релиз.

  

elCust

9 — 11.10.18 — 17:54

Файловая без ошибок обновилась на 3.0.65.80.

Правда пустая.

Платформа 8.3.12.1616.

  

jk3

10 — 11.10.18 — 17:57

(9) Демо-база БП у меня без ошибок обновилась до 3.0.65.80 на платформе 8.3.12.1595.

А вот копия реальной базы — фиг.

  

МихаилМ

11 — 11.10.18 — 21:13

(10) значит ТЖ в руки и исправляйте ошибку.

  

jk3

12 — 14.10.18 — 23:26

Та же самая ошибка на последней платформе 8.3.13.1513.

(11) Как надо настроить тех.журнал, чтобы попытаться самостоятельно отловить ошибку?

  

hhhh

13 — 14.10.18 — 23:40

(12) всё ж таки проверьте планы обмена. наверняка левый узел там кто-то создал.

  

MSOliver

14 — 15.10.18 — 04:32

Ошибка зарегистрирована?

  

jk3

15 — 15.10.18 — 10:21

(13) Это я первым делом проверил.

В плане обмена «Полный» только один предопределенный элемент без кода, наименования, т.е. который не использовался никогда.

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

У всех остальных, кроме 3-х (ниже), точно такая же картина с одним предопределенным элементом.

"Обновление информационной базы" -- кроме предопределенного еще 5 обычных элементов.
"Синхронизация данных через универсальный формат" -- 2 элемента: один предопределенный и еще один обычный элемент.
"Управление торговлей, редакция 11" -- 2 элемента: один предопределенный, а второй помечен на удаление.

  

jk3

16 — 15.10.18 — 10:21

(14) Еще в субботу написал на v8, но, такое ощущение, что по выходным они почту не обрабатывают.

  

jk3

17 — 15.10.18 — 10:44

Только вот сейчас ответили «Ваше письмо будет рассмотрено в ближайшее время».

  

hhhh

18 — 15.10.18 — 10:55

(15) ну вот, тот что помечен на удаление, удалите нахрен. Бывших узлов не бывает.

  

MSOliver

19 — 16.10.18 — 07:25

Я обновился без проблем.

  

jk3

20 — 16.10.18 — 10:06

(18) Его невозможно удалить, на него куча ссылок, т.к. раньше до EnterpriseData этот обмен использовался.

Да и я думаю он никак не влияет, какой-то косяк с планом обмена Полный, а не с ним.

  

jk3

21 — 16.10.18 — 10:06

(19) Поздравляю!

А мне даже еще не ответили в какую сторону хотя бы копать.

  

hhhh

22 — 16.10.18 — 10:08

(20) вот именно он и влияет. Так что тянуть с удалением нет смысла.

  

vladko

23 — 16.10.18 — 10:46

Обновил в выходные типовую рабочая базу. Без проблем обновилась и работает на рекомендованной платформе 8.3.12.1529 (правда в базе не используются синхронизации)

  

Naumov

24 — 16.10.18 — 12:12

(23) У пользователей с ограниченными правами при поиске в динамическом списке (например в документах реализации) ошибок не возникает?

  

El_Duke

25 — 16.10.18 — 12:45

(21) Ответили, ты не захотел увидеть

В (3) этот ответ прозвучал. Я на платформе 8.3.12.1685 обновился успешно, только долго адски

  

crotnn

26 — 16.10.18 — 12:47

(21) У меня при запуске самописки на 8.3.12 в планах обмена самопроизвольно очистились значения реквизита «ЭтотУзел» у всех узлов всех планов обмена, и тоже посыпались ошибки. После «ручной» установки значений все заработало. Проверь на всякий случай.

  

jk3

27 — 16.10.18 — 14:22

(25) Пробовал на платформах 8.3.12.1595, 8.3.12.1685, 8.3.13.1513 — результат одинаковый как в (0)

  

jk3

28 — 16.10.18 — 14:23

Попробовал выгрузить базу в dt-файл и загрузить обратно. Не помогло.

  

jk3

29 — 16.10.18 — 14:25

(26) А как это сделать?

После наката обновления по F7 и старта базы как-то можно отказаться от запуска обновления в предприятии?

  

1c_asadi

30 — 16.10.18 — 14:29

(0) Попробуй запустить тестирование(без исправления) с 4я первыми галками сразу после завершения обновления в конфигураторе, была такая беда с типовой — помогло.

  

jk3

31 — 16.10.18 — 14:43

(26) В окне «Не удалось выполнить обновление» есть кнопка Еще — Открыть внешнюю обработку.

Запустил внешнюю обработку с таким кодом:

Сообщить(ПланыОбмена.Полный.ЭтотУзел().ЭтотУзел);

Выдает «Да».

Т.е. значение реквизита не слетело.

  

Naumov

32 — 16.10.18 — 14:45

(29) Нет, после наката только из архивной копии

  

crotnn

33 — 16.10.18 — 14:51

(31) я бы и остальные планы обмена так проверил, не только полный. Ведь в (0) явно ошибка в каком-то узле обмена. В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.

  

jk3

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С молчит как партизан.

  

Bony-andrey

35 — 16.10.18 — 15:44

У меня было слегка похожая ситуация при переходе БП 2.0 -> 3.0

Таблица была «dbo._AccRgAT2486», SQL ругался на неуникальность конкретного индекса. В Management Studio я временно разрешил этому конкретного индекса пропускать повторяющиеся значения,а после выполнения всех процедур обратно запретил.

Но что за таблица «dbo._tmpRCT»?

  

1c_asadi

36 — 16.10.18 — 15:57

(34) вышел еще 84 релиз БП мож там поправили,как вариант попробуй в файловый вариант сконвертить и там обновить

  

jk3

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 — строка с таким значением есть.

Хз почему пытается вставить в эту таблицу еще одно такое значение. Естественно, скуль не даёт это сделать.

  

jk3

38 — 16.10.18 — 17:42

(36) Попробовал накатить 3.0.65.84 релиз. Ошибка та же.

  

jk3

39 — 16.10.18 — 17:56

При ТИИ базы до обновления в таблице _tmpRCT это значение 0x0000001B так же есть, но количество строк в таблице 1268 (больше).

Т.е. получается на базе после обновления спотыкается на дублирующимся ключе и недозаполняет таблицу.

Где хранится обратная связь ID таблиц с человеческим наименованием?

Чтобы хотя бы попытаться понять что где задублировалось при обновлении.

  

1c_asadi

40 — 17.10.18 — 07:49

(39)для таких целей писал обработку, если нужна напиши почту — скину

https://cloud.mail.ru/public/DTQ1/B9ZWfDtnW типо так умеет

  

jk3

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 триггера отключите  индекс

  

jk3

43 — 17.10.18 — 23:30

(33) >я бы и остальные планы обмена так проверил, не только полный

Вот такой код выдает «Да» и в битой базе после обновления, и в нормальной до обновления:

    Для Каждого ТекПланОбмена Из Метаданные.ПланыОбмена Цикл
        Сообщить(ТекПланОбмена.Имя + " = " + ПланыОбмена[ТекПланОбмена.Имя].ЭтотУзел().ЭтотУзел);
    КонецЦикла;

  

jk3

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 и меняется режим совместимости.

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

  

jk3

45 — 19.10.18 — 11:43

При возврате режима совместимости 8.3.12 => 8.3.10 ТИИ ошибок не выдает… хм.

  

МихаилМ

46 — 19.10.18 — 12:14

(44)

"как починить базу.."

либо исправить исходные данные, приводящие к ошибке.

либо созданные.

первое решается путем расследования тж либо трасс ms sql profiler на предмет , откуда 1с8 берет данные для таблицы с последующим исправлением.

второе — отключением индекса при создании таблицы, удаления дублей, создание индекса.

  

jk3

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), всё еще остается.

  

jk3

48 — 23.10.18 — 23:39

(33) >В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.

Удалил обработкой все непредопределенные элементы всех планов обмена (у которых свойство ЭтотУзел = Ложь) перед обновлением.

Та же ошибка после обновления при обработке данных в предприятии.

  

jk3

49 — 25.10.18 — 16:31

(36) >как вариант попробуй в файловый вариант сконвертить и там обновить

На файловой базе та же ошибка.

ТИИ и chdbfl и до, и после(!) обновления рапортуют, что проблем нет.

При этом, если при появлении ошибки обновления в предприятии открыть обработкой элемент плана обмена Полный и попробовать записать — вываливается в ошибку SDBL.

  

jk3

50 — 31.10.18 — 23:41

Ответ поддержки 1С, цитата:

Проблема возникает, если загрузить dt сформированной более новой версией (в более новом режиме совместимости). Теперь при попытке загрузить такой dt возникает ошибка. Базы, сформированные такой загрузкой ранее некоректны и с ним работать не получится. Исправление на них не влияет.

Вам необходимо загрузить базу на том релизе платформы, на котором она была сделана. После этого уже выполнять обновление платформы и обновление.

Если это не так, то следует прислать dt вашей базы, сделанные до обновления и на платформе 8.3.10
Помогите перевести этот ответ на русский.

Что надо сделать?

P.S. Я им отправлял .bak-файл MSSQL-бэкапа текущей базы до обновления.

  

jk3

51 — 09.11.18 — 11:44

Новости с полей: «Ваше сообщение зарегистрировано для расследования в отделе разработки <номер>».

  

Mankubus

52 — 21.11.18 — 11:26

(51) не удалось решить проблему?

  

jk3

53 — 30.11.18 — 16:20

(52) Прошло 3 недели, ответа от отдела разработки 1С нет.

Напомнил им сегодня о себе.

Посмотрим на следующей неделе что ответят.

  

jk3

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 не рассматривали ? И на новой базе уже проводить обновление.

  

shuhard

57 — 25.12.18 — 15:08

(55)[То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.]

ты бредишь и тяжело, не запуская болезнь

  

ЧессМастер

58 — 25.12.18 — 15:13

(57) Если ты один айтишник который обслуживает организацию и о твоей идее слить базу куда-то (пусть и с целью починить) никто не узнает то можешь делать что угодно.

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

  

jk3

59 — 04.01.19 — 10:12

В общем, исправления бага я так и не дождался, решил проблему обновления в предприятии правкой кода:

ОбщийМодуль.СтандартныеПодсистемыСервер
Процедура ЗарегистрироватьОбъектНаВсехУзлах()
            Если ПланыОбмена[ИмяПланаОбмена].ЭтотУзел() = Неопределено Тогда
                Возврат;
            КонецЕсли;

И благополучно обновился до последнего релиза.

ТИИ с исправлением ссылок так и не запускается с ошибкой PRIMARY KEY, но, я думаю, что это ошибка в платформе и когда-нибудь она сама пропадет.

  

jk3

60 — 05.01.19 — 22:23

У этой истории неожиданно появилось продолжение.

При попытке загрузки данных из УТ:

Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы

  

  

jk3

61 — 05.01.19 — 22:25

(56) Видимо, придётся воспользоваться вашим советом.

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

Подскажите, как это сделать?

  

sergey yevsenya

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 эти ошибки ТИИ при реструктуризации ушли ?

  

sergey yevsenya

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)"

При простом ТИИ выдает ошибку

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

При этом под релизом 8.3.10.2561 ТИИ проходит без ошибок.

  

jk3

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 или может быть какая-то особенная обработка нужна?

to continue to Google Sites

Not your computer? Use Guest mode to sign in privately. Learn more

   jk3

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

поняли. а что хотели? предупредть ?

   jk3

2 — 11.10.18 — 17:32

(1) Что делать чтобы обновилось без этой ошибки?

Всё делал на тестовой базе.

Рабочую, естественно, оставил пока на релизе 3.0.64.54.

Но рано или поздно придётся обновлять, а тут такая Ж.

Может быть кто-то уже столкнулся с тем же самым и смог победить.

   Amra

3 — 11.10.18 — 17:33

Более свежий релиз платформы попробуй, из 12ых

   dka80

4 — 11.10.18 — 17:34

(2) вы не первый, кто жалуется на ошибки при переходе на этот релиз. Поэтому лучше переждать

   jk3

5 — 11.10.18 — 17:39

Да, забыл уточнить, что никакого РИБ в помине нет. Это одиночная база.

   jk3

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

   VladZ

7 — 11.10.18 — 17:41

(0) Последнюю платформу (8.3.13) не пробовал ставить?

   jk3

8 — 11.10.18 — 17:46

(7) Я таким экстримом не занимаюсь))

Обновляю платформу только по надобности и не на самый последний релиз.

   elCust

9 — 11.10.18 — 17:54

Файловая без ошибок обновилась на 3.0.65.80.

Правда пустая.

Платформа 8.3.12.1616.

   jk3

10 — 11.10.18 — 17:57

(9) Демо-база БП у меня без ошибок обновилась до 3.0.65.80 на платформе 8.3.12.1595.

А вот копия реальной базы — фиг.

   МихаилМ

11 — 11.10.18 — 21:13

(10) значит ТЖ в руки и исправляйте ошибку.

   jk3

12 — 14.10.18 — 23:26

Та же самая ошибка на последней платформе 8.3.13.1513.

(11) Как надо настроить тех.журнал, чтобы попытаться самостоятельно отловить ошибку?

   hhhh

13 — 14.10.18 — 23:40

(12) всё ж таки проверьте планы обмена. наверняка левый узел там кто-то создал.

   MSOliver

14 — 15.10.18 — 04:32

Ошибка зарегистрирована?

   jk3

15 — 15.10.18 — 10:21

(13) Это я первым делом проверил.

В плане обмена «Полный» только один предопределенный элемент без кода, наименования, т.е. который не использовался никогда.

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

У всех остальных, кроме 3-х (ниже), точно такая же картина с одним предопределенным элементом.

"Обновление информационной базы" -- кроме предопределенного еще 5 обычных элементов.
"Синхронизация данных через универсальный формат" -- 2 элемента: один предопределенный и еще один обычный элемент.
"Управление торговлей, редакция 11" -- 2 элемента: один предопределенный, а второй помечен на удаление.
   jk3

16 — 15.10.18 — 10:21

(14) Еще в субботу написал на v8, но, такое ощущение, что по выходным они почту не обрабатывают.

   jk3

17 — 15.10.18 — 10:44

Только вот сейчас ответили «Ваше письмо будет рассмотрено в ближайшее время».

   hhhh

18 — 15.10.18 — 10:55

(15) ну вот, тот что помечен на удаление, удалите нахрен. Бывших узлов не бывает.

   MSOliver

19 — 16.10.18 — 07:25

Я обновился без проблем.

   jk3

20 — 16.10.18 — 10:06

(18) Его невозможно удалить, на него куча ссылок, т.к. раньше до EnterpriseData этот обмен использовался.

Да и я думаю он никак не влияет, какой-то косяк с планом обмена Полный, а не с ним.

   jk3

21 — 16.10.18 — 10:06

(19) Поздравляю!

А мне даже еще не ответили в какую сторону хотя бы копать.

   hhhh

22 — 16.10.18 — 10:08

(20) вот именно он и влияет. Так что тянуть с удалением нет смысла.

   vladko

23 — 16.10.18 — 10:46

Обновил в выходные типовую рабочая базу. Без проблем обновилась и работает на рекомендованной платформе 8.3.12.1529 (правда в базе не используются синхронизации)

   Naumov

24 — 16.10.18 — 12:12

(23) У пользователей с ограниченными правами при поиске в динамическом списке (например в документах реализации) ошибок не возникает?

   El_Duke

25 — 16.10.18 — 12:45

(21) Ответили, ты не захотел увидеть

В (3) этот ответ прозвучал. Я на платформе 8.3.12.1685 обновился успешно, только долго адски

   crotnn

26 — 16.10.18 — 12:47

(21) У меня при запуске самописки на 8.3.12 в планах обмена самопроизвольно очистились значения реквизита «ЭтотУзел» у всех узлов всех планов обмена, и тоже посыпались ошибки. После «ручной» установки значений все заработало. Проверь на всякий случай.

   jk3

27 — 16.10.18 — 14:22

(25) Пробовал на платформах 8.3.12.1595, 8.3.12.1685, 8.3.13.1513 — результат одинаковый как в (0)

   jk3

28 — 16.10.18 — 14:23

Попробовал выгрузить базу в dt-файл и загрузить обратно. Не помогло.

   jk3

29 — 16.10.18 — 14:25

(26) А как это сделать?

После наката обновления по F7 и старта базы как-то можно отказаться от запуска обновления в предприятии?

   1c_asadi

30 — 16.10.18 — 14:29

(0) Попробуй запустить тестирование(без исправления) с 4я первыми галками сразу после завершения обновления в конфигураторе, была такая беда с типовой — помогло.

   jk3

31 — 16.10.18 — 14:43

(26) В окне «Не удалось выполнить обновление» есть кнопка Еще — Открыть внешнюю обработку.

Запустил внешнюю обработку с таким кодом:

Сообщить(ПланыОбмена.Полный.ЭтотУзел().ЭтотУзел);

Выдает «Да».

Т.е. значение реквизита не слетело.

   Naumov

32 — 16.10.18 — 14:45

(29) Нет, после наката только из архивной копии

   crotnn

33 — 16.10.18 — 14:51

(31) я бы и остальные планы обмена так проверил, не только полный. Ведь в (0) явно ошибка в каком-то узле обмена. В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.

   jk3

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С молчит как партизан.

   Bony-andrey

35 — 16.10.18 — 15:44

У меня было слегка похожая ситуация при переходе БП 2.0 -> 3.0

Таблица была «dbo._AccRgAT2486», SQL ругался на неуникальность конкретного индекса. В Management Studio я временно разрешил этому конкретного индекса пропускать повторяющиеся значения,а после выполнения всех процедур обратно запретил.

Но что за таблица «dbo._tmpRCT»?

   1c_asadi

36 — 16.10.18 — 15:57

(34) вышел еще 84 релиз БП мож там поправили,как вариант попробуй в файловый вариант сконвертить и там обновить

   jk3

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 — строка с таким значением есть.

Хз почему пытается вставить в эту таблицу еще одно такое значение. Естественно, скуль не даёт это сделать.

   jk3

38 — 16.10.18 — 17:42

(36) Попробовал накатить 3.0.65.84 релиз. Ошибка та же.

   jk3

39 — 16.10.18 — 17:56

При ТИИ базы до обновления в таблице _tmpRCT это значение 0x0000001B так же есть, но количество строк в таблице 1268 (больше).

Т.е. получается на базе после обновления спотыкается на дублирующимся ключе и недозаполняет таблицу.

Где хранится обратная связь ID таблиц с человеческим наименованием?

Чтобы хотя бы попытаться понять что где задублировалось при обновлении.

   1c_asadi

40 — 17.10.18 — 07:49

(39)для таких целей писал обработку, если нужна напиши почту — скину

https://cloud.mail.ru/public/DTQ1/B9ZWfDtnW типо так умеет

   jk3

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 триггера отключите  индекс

   jk3

43 — 17.10.18 — 23:30

(33) >я бы и остальные планы обмена так проверил, не только полный

Вот такой код выдает «Да» и в битой базе после обновления, и в нормальной до обновления:

    Для Каждого ТекПланОбмена Из Метаданные.ПланыОбмена Цикл
        Сообщить(ТекПланОбмена.Имя + " = " + ПланыОбмена[ТекПланОбмена.Имя].ЭтотУзел().ЭтотУзел);
    КонецЦикла;
   jk3

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 и меняется режим совместимости.

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

   jk3

45 — 19.10.18 — 11:43

При возврате режима совместимости 8.3.12 => 8.3.10 ТИИ ошибок не выдает… хм.

   МихаилМ

46 — 19.10.18 — 12:14

(44)

«как починить базу..»

либо исправить исходные данные, приводящие к ошибке.

либо созданные.

первое решается путем расследования тж либо трасс ms sql profiler на предмет , откуда 1с8 берет данные для таблицы с последующим исправлением.

второе — отключением индекса при создании таблицы, удаления дублей, создание индекса.

   jk3

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), всё еще остается.

   jk3

48 — 23.10.18 — 23:39

(33) >В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.

Удалил обработкой все непредопределенные элементы всех планов обмена (у которых свойство ЭтотУзел = Ложь) перед обновлением.

Та же ошибка после обновления при обработке данных в предприятии.

   jk3

49 — 25.10.18 — 16:31

(36) >как вариант попробуй в файловый вариант сконвертить и там обновить

На файловой базе та же ошибка.

ТИИ и chdbfl и до, и после(!) обновления рапортуют, что проблем нет.

При этом, если при появлении ошибки обновления в предприятии открыть обработкой элемент плана обмена Полный и попробовать записать — вываливается в ошибку SDBL.

   jk3

50 — 31.10.18 — 23:41

Ответ поддержки 1С, цитата:

Проблема возникает, если загрузить dt сформированной более новой версией (в более новом режиме совместимости). Теперь при попытке загрузить такой dt возникает ошибка. Базы, сформированные такой загрузкой ранее некоректны и с ним работать не получится. Исправление на них не влияет.

Вам необходимо загрузить базу на том релизе платформы, на котором она была сделана. После этого уже выполнять обновление платформы и обновление.

Если это не так, то следует прислать dt вашей базы, сделанные до обновления и на платформе 8.3.10

Помогите перевести этот ответ на русский.

Что надо сделать?

P.S. Я им отправлял .bak-файл MSSQL-бэкапа текущей базы до обновления.

   jk3

51 — 09.11.18 — 11:44

Новости с полей: «Ваше сообщение зарегистрировано для расследования в отделе разработки <номер>».

   Mankubus

52 — 21.11.18 — 11:26

(51) не удалось решить проблему?

   jk3

53 — 30.11.18 — 16:20

(52) Прошло 3 недели, ответа от отдела разработки 1С нет.

Напомнил им сегодня о себе.

Посмотрим на следующей неделе что ответят.

   jk3

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 не рассматривали ? И на новой базе уже проводить обновление.

   shuhard

57 — 25.12.18 — 15:08

(55)[То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.]

ты бредишь и тяжело, не запуская болезнь

   ЧессМастер

58 — 25.12.18 — 15:13

(57) Если ты один айтишник который обслуживает организацию и о твоей идее слить базу куда-то (пусть и с целью починить) никто не узнает то можешь делать что угодно.

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

   jk3

59 — 04.01.19 — 10:12

В общем, исправления бага я так и не дождался, решил проблему обновления в предприятии правкой кода:

ОбщийМодуль.СтандартныеПодсистемыСервер
Процедура ЗарегистрироватьОбъектНаВсехУзлах()
            Если ПланыОбмена[ИмяПланаОбмена].ЭтотУзел() = Неопределено Тогда
                Возврат;
            КонецЕсли;

И благополучно обновился до последнего релиза.

ТИИ с исправлением ссылок так и не запускается с ошибкой PRIMARY KEY, но, я думаю, что это ошибка в платформе и когда-нибудь она сама пропадет.

   jk3

60 — 05.01.19 — 22:23

У этой истории неожиданно появилось продолжение.

При попытке загрузки данных из УТ:

Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы
   jk3

61 — 05.01.19 — 22:25

(56) Видимо, придётся воспользоваться вашим советом.

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

Подскажите, как это сделать?

   sergey yevsenya

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 эти ошибки ТИИ при реструктуризации ушли ?

   sergey yevsenya

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 ТИИ проходит без ошибок.

   jk3

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 оператор insert вложенный в оператор update
  • Ошибка sdbl ожидается имя таблицы pos 49 1с
  • Ошибка sdbl ожидается выражение pos 112
  • Ошибка sdbl ожидается create drop rename replace или select
  • Ошибка sdbl недопустимое преобразование типов