1с внутренняя ошибка при реконструкции запроса

Обновлено: 03.07.2024

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

В статье расскажем, как решали возникающие вопросы по настройкам Internet Information Services. Через призму своего опыта и коллег.

Сертификат выдается сроком на 90 дней. Для автоматического продления создается периодическое задание в Планировщике. При запуске задачи сайт должен быть доступен (пройти проверку домена) по 80-му порту.

II. Типовая настройка и публикация информационных баз на IIS

На что обратить внимание:

1. Состав компонентов IIS — в Интернете полно инструкций и указаний. Повторяться не будем.

2. Установка 1С необходимой разрядности . Варианта 2: x86 (32-разрядное приложение) или x64. Обязательно выбираем «Модули расширения веб-сервера».

3. Права для встроенной группы /пользователю веб-сервера (IUSR) на папки:

  • с установленной платформой — на «чтение и выполнение» (для старта процессов);
  • самих расположений ИБ — на «изменение» (в случае файлового варианта).

4. Публикация базы через Конфигуратор 1С . Возможно потребуется открыть программу с повышенными правами — «Запуск от имени администратора».

5. Для 32-разрядного клиента 1С в диспетчере IIS включаем разрешение запуска ( DefaultAppPool — Дополнительные параметры — Разрешены 32-разрядные приложения = True ). Для 1C x64 — значение не меняем.

6. На странице сопоставления обработчиков для «1С Web-service Extension» потребуется указать путь к исполняемому модулю :

  • x86 — «C:\Program Files (x86)\1cv8\8.3.x.xx\bin\wsisapi.dll»;
  • x64 — «C:\Program Files\1cv8\8.3.x.xx\bin\wsisapi.dll».

Либо изменяем путь к библиотеке в файлах web.config через Блокнот (располагается, как правило, в c:\inetpub\wwwroot\<имя базы>).

Если в п. 2 все сделано правильно — по указанному пути должен присутствовать файл wsisapi.dll.

7. В частных случаях требуется перезапуск служб IIS . Выполните «Перезапустить» в оснастке управления или перезагрузите сервер.

✅ Соблюдаем соответствие разрядности: если запускаем и публикуем 64-разрядный клиент 1С:Предприятие, то dll также должна быть 64-битной версии.

Если публикуем 32-разрядную версию 1С, то ставим разрешение запуска 32-разрядных приложений на IIS и проверяем путь к wsisapi из каталога x86.

III. Если клиент 1С зависает при подключении к базе по web

Прежде посмотрите этот материал — там общие рекомендации.

Другой случай. Файловая ИБ опубликована на IIS. После авторизации зависает на эмблеме 1С. При открытии Конфигуратора — все нормально.

В журналах Windows ошибка «Процесс, обслуживающий пул приложений "1С", не ответил на команду ping».

  • проверьте права на папку с базой 1С для IUSR/IIS_IUSRS, уровень доступа — на «изменение»;
  • в оснастке IIS «Пулы приложений — <пул_1С> — Дополнительные параметры — Модель процесса» задайте для « Максимальная задержка отклика при проверке связи » значение, превышающее 90 секунд;
  • посмотрите на поведение IIS при «Проверка связи включена» = False.
📝 Из справки: установка [pingingEnabled] (Проверка связи) в значение false не позволит IIS проверять, выполняется ли рабочий процесс, и таким образом сохранит его активным до остановки процесса отладки.

✅ Установка «Максимальное время отклика пинга» в большое значение позволит IIS продолжать наблюдение за рабочим процессом.

Информационная база 1C опубликована на IIS. При работе через тонкий клиент, при нажатии на «Отчеты» вываливается ошибка.

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

✅ Откройте настройки пула приложений и проверьте «Режим управляемого конвейера» = «Classic».

Приветствую!
Обновил платформу с 8.3.10 на релиз 8.3.11 и теперь вот такая ошибка вываливается при проведении документа ПТИУ и ПКО
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
по причине:
Ошибка при выполнении операции с информационной базой
Запись не найдена в менеджере имен базы данных.

Подскажите, кто знает

(1) Так 8.3.11 - это же пока тестовая, кто же знает, что там за ошибки. (2)Ну это понятно. Только там вкусность есть одна, которая нужна мне - добавление реквизитов и ТЧ в расширения.

05.09.17 опубликована версия 8.3.11.2571, предназначена для тестирования

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

1С:Предприятие 8.3 (8.3.11.2571)

Управление торговлей, редакция 11 (11.3.4.30

а у вас базовая или Проф ?

(12)Я снес старые версии платформы, установил новую, под ней развернул дт, убрал режим совместимости. На файловой у меня не завелось. Я просто развернул ее из шаблона и та же фигня но ошибка после обновления платформы была таже, откатился на старую конфу в обновлении, заработало. теперь обновляю конфу Так какая правильная последовательность должна быть? Накатываем платформу, потом обновление ставим, потом снимаем режим совместимости? (28)В том и фишка - надо выставить в режим "не использовать", чтобы добавить реквизиты в расширение (31)попробую тем более что у меня тоже задействовано расширение в вашем случае при восстановлении из DT обновиться из шаблона на предыдущий релиз УТ 3.40, у меня такой был. и дальше пробую обновить до текущего (34)Вышла новая платформа. Пока полет нормальный - косяк этот ушел Не вижу выхода 8.3.11, вижу последнюю 8.3.10.2561 от 11 августа 2017
8.3.11 - пока тестовый. Релиз запланирован на 17.10.2017. (39)О чем и я, в утвержденных релизах его нет, только в тестовых. Вообще конечно это риск, пробовать рисковать данными на тестовом софте))) (42)Нет, бэкап не всегда помогает, многое может проявиться совсем не сразу.
Пользователям может не понравиться, если за 1-2 недели снова данные вводить придется. )

Запись не найдена в менеджере имен базы данных.

Подскажите, пожалуйста, есть решение? На релизе тоже появилось.

Нафига вы на 11 платформу обновляетесь, не пойму. Для всех типовых 10 пока подходит. (47)Не скажите. Мелькало тут как-то, как раз с УТ. Народ жаловался, что УТ требует при обновлении 11 релиза платформы (48)Чет не видал я что 11 требует, у меня УТ11 на 10 норм обновляется, без претензий. (49)В общем с какой-то из последних релизов люди жаловались, сейчас точно тему не найду) (50) ERP последней версии требует 8.3.10.2466. А все УТ11 это кусок ERP.

Появилась похожая ошибка (конфигурация нетиповая, платформа 8.3.11.2867)

Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка при выполнении операции с информационной базой
Запись не найдена в менеджере имен базы данных

После чего сеанс завершается

В случае если загружаемый "ЭлементДанных" не входит в состав плана обмена с которым выполняется обмен.
Включил в состав плана обмена (в моем случае это был регистр сведений на котором был обмен в одну сторону) и ошибка исчезла.

(52) Та же ошибка в не типовой конфигурации "Ошибка при выполнении операции с информационной базой. Запись не найдена в менеджере имен базы данных". Решение такое же. При регистрации в плане обмена всех объектов метаданных, которые ранее ходили в одну сторону (с отключением авторегистрации), обмен заработал. (53) аналогичная проблема при обмене. можно поподробней что нужно сделать чтобы обмен заработал ? (54) Утро тоже началось с ошибки после обновления) Нужно в базе приемнике в составе обмена включить регистрацию объектов которые выгружаются из базы источника. а как определить какие обьекты не включены с состав обмена? (56) Сравнить глазами два Состава плана обмена в двух разных базах. У меня время поджимало и я включил регистрацию для всех объектов, запретив авторегистрацию. (56) У меня чуть проще, порядка 10 объектов нужно регистрировать . да и я знаю что именно у меня не было включено в обмен, но Александр написал правильно, нужно просто в базе источнике посмотреть в плане обмена, что именно зарегестрировано к обмену и те же объекты прописать в плане обмена в базе приёмнике, но отключив авторегистрацию для данных объектов (чтобы лишние записи не создавались при изменении этих регистров, справочников, документов и т.д.).

Где
Отправитель - Узел плана обмена
Данные - собственно прилетевшие данные в базу

Хех, нашел второй вариант таблетки:

Тоже работает на ура.

(61) У меня не срабатывает в попытке - платформа все равно падает, что логично.

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

Данная ошибка "Запись не найдена в менеджере имен базы данных." вылезает при реструктуризации базы данных из под конфигуратора.
Все остальные галки сняты только реструктуризация, куда копать ?

Со стороны пользователей в 1С все абсолютно все работает. Все документы проводятся, в общем все штатно.

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

Куда копать подскажите ?

(62)Чем вам не сидится на 8.3.10.ххх, или конфигурация требует 8.3.11.ххх.

Теперь требует :) (из за продвинутых возможностей расширений в большей степени) но на 8.3.10 реструктуризация работает штатно.

Сейчас выявили предполоение что из за агрегатов которые включены на регистре об который спотыкается реструктуризация вываливается данная ошибка.

В выходные буду пробовать удалять агрегаты и повторно проводить реструктуризацию.

К слову "Чем вам не сидится на 8.3.10.ххх".
У нас база близится к 400 (сейчас перевалила за 350) гигам, и реструктуризация скажем таки прямо - дело "тухлое" в старых версиях. Делали только когда были праздники захватывающие выходные (то есть чтобы 3 дня получлоась)
В 8.3.11 1С изменили подход к реструктуризации насколько я понял. Хочется проверить так ли это, чтобы поставить эту штуку на автоматический регламент хотя бы раз в 3-4 месяца. но для этого надо чтобы реструктуризация хотя бы ручками выполнялась.

Пересчет итогов средствами конфигуратора идет каждые выходные, но благодаря сильному серверу и RAID-у на SSD дисках пересчет итогов идет около полутора часов иногда 3 часа когда были сильные изменения по регистрам.

Похожая ситуация, но расширение никакие не получилось завести.
8.3.11.3034

взял конфигурацию ЕРП, убрал режим совместимости, создал расширение. Версия БСП 2.3.2
И после разных манипуляций, расширение вообще пропадает из конфигуратора.

Каких только ошибок не насмотрелся:

1.
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Транзакция активна. Индексы выключать нельзя

2.
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка при выполнении операции с информационной базой
Запись не найдена в менеджере имен базы данных.

Может лучше оставить Режим совместимости Версия 8.3.10?

(67) да, Вадим, народ так и пишет, но смысл публиковать работу с расширением, если пользоваться не возможно

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

(68) Если на Версия 8.3.10 все работает, то логично предположить, что ошибки связаны с платформой. Следовательно остается только ждать новую платформу, а пока работать на совместимости с 8.3.10. Мы так и делаем. (68) Такая ошибка еще может возникать, когда одно из расширений, которое использует расширение данных, не удалось подключить или для него не установлен флаг активности. Как только все расширения успешно подключатся, будет доступна запись.

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

4. 8.3.12.1412 даже нельзя выполнить запрос в консоле по добавленному в расширение регистру

Ошибка при выполнении обработчика - 'ОбработкаПроведения'
по причине:
: Ошибка при вызове метода контекста (Выполнить)
Результат = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("ИмяРегистра");
по причине:
Ошибка выполнения запроса
по причине:
Нельзя использовать таблицу без указания всех разделителей с независимым использованием разделяемых данных
объект: 'РегистрСведений. (регистр добавленный в расширение)

Почтальон Печкин 1С-кин:
"У меня для вас есть регистр сведений в расширениях, но использовать его вы не сможете!"

При попытке удаления расширения в конфигураторе

------
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Некорректное использование LOCAL/GLOBAL в SET GENERATION.
------

но снять "Активность" получилось

При попытке удаления расширения в Предприятии:

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

(73)
Как-то разгреблось постепенно. Баг это понятно.
Но наверное помогло то, что постепенно удалял из расширения последние добавленные объекты (предварительно сохранив конфу расширения)
И так по одному объекту удаляя и сохраняя каждый раз - вроди позволило. Т.е. целиком удаляя или если много сразу объектов удалять - падает. А по одному - вроди постепенно помогает.

новиночка в процессе удаления расширения

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Невозможно вставить повторяющуюся ключевую строку в объект "dbo._Reference41587" с уникальным индексом "_Reference41587_S_HPK".
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2601, line=1

Продолжаем с внезапно перестающими работать и удаляться расширениями
8.3.13.1198 x64 файловая

При ТИИ Проверка логической целостности прерывается ошибкой:

Ошибка SDBL:
Таблица или поле Fld1507 не содержится в разделе FROM (pos = 7)

8.3.13 файловая (в отличие от 8.3.12) таки удалило расширение.
Сначала сказала что нужно сначала снять активность, а потом все получилось.
Но Тестирование после удаления расширения все равно не проходит с той же ошибкой

Зуп требует обновить платформу. Списки ошибок у релизов какие-то стрёмные. На что обновляться? 8.3.10/11/12 ? (80) мне кажется что если не пользуетесь расширениями, то можно и на 8.3.12
в последних поболе ошибок исправлено, особенно в 8.3.13
но большинство ошибок простым к смертным конфигурациям не относятся

(82) те новинки которые добавлены расширением 8.3.11 (регистры, перечисления) - не рабочие
базу можно погубить.
у меня висит сейчас такая база, которая теперь и не тестится.

Итак, обновление….
Напомню, есть база на SQL УТП+доработки с отключенной совместимостью, в которой развивалось расширение.
В какой-то момент после доработок расширения на 8.3.11 или 8.3.12 стало не возможным вносить любые изменения в расширение.
Конфигуратор падал дампом

Вышла новая платформа 8.3.12.1595. и дело немного сдвинулось с мертвой точки.
Теперь конфигуратор во время сохранения конфигурации расширения не падает, а выдает ошибку:

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Некорректное использование LOCAL/GLOBAL в SET GENERATION.

Причем в строке состояния видно, что остановлено на реструктуризации объекта:

Последовательность.ПартионныйУчет.Таблица границ последовательности

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

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

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

Обновились на Платформа: 1С:Предприятие 8.3 (8.3.15.1747) и понеслось:

Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
Недостаточно свободной памяти для выполнения операции

Кто как боролся, особенно на сервере 2003 ??

Использовать 64-х разрядную версию ОС и оперативную память 8Gb и больше

Тоесть я устанавливаю версию для работы в 32-х битной системе, но от меня требуют 64-х битную, это ли не косяк 1С, который они не желают исправлять?

А чего тут бороться? Написано же "недостаточно памяти".
Увеличиваете память и всё.
На 64 переходить не обязательно.

Девушка, милая, на 32 разрядной ОС ограничение в 4 ГБ. Из них ОС задействует под программы 2 и 2 оставляет для системных задач. Можно только перераспределить.

SoNik ,
судя по тексту ошибки, надо просто обрезать и настроить размер ЖР - Журнал Регистрации

Ответили же уже выше:
- уменьшите (размер) ЖР и
- увеличте размер , выделяемой под процессы 1С оперативной памяти
- удалите ненужное

Гугль сразу же выдаёт ссылки на
bcdedit /set increaseuserva

Контрольное Cоотношение Равенство пишет:

я так понимаю выделяемая память это функция: bcdedit /set increaseuserva?

а про уменьшить размер ЖР можно чуть подробнее?

Читают тему:

Мероприятия

1C:Лекторий: 25 ноября 2021 года (четверг, начало в 12:00) — Специальные механизмы в "1С:ЗУП 8" (ред. 3)

  • Где купить СОФТ
  • Вакансии фирм-партнеров "1С"
  • Центры Сертифицированного Обучения
  • Интернет курсы обучения "1С"
  • Самоучители
  • Учебный центр № 1
  • Учебный центр № 3
  • Сертификация по "1С:Профессионал"
  • Организация обучения под заказ
  • Книги по 1С:Предприятию

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

Редакция БУХ.1С не несет ответственности за мнения и информацию, опубликованную в комментариях к материалам.

Редакция уважает мнение авторов, но не всегда разделяет его.

Дизайн сайта

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

Такую ошибку показывает 1С и немногословно предлагает « Завершить работу » или « Перезапустить. ». Приятного мало. У клиента ошибка возникла при работе с файловой базой 1С 8.2 в общем доступе (БП 2.0).

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

«Ошибка СУБД: Внутренняя ошибка компоненты dbeng8» при работе в 1С «Ошибка СУБД: Внутренняя ошибка компоненты dbeng8» при работе в 1С

I. Как выглядит ошибка

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

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

Из-за чего? Наиболее вероятная причина — вследствие нарушений структуры БД, ошибки при записи транзакций, сбой хранилища.
Может быть вызвано некорректным закрытием 1С из-за отключения электроэнергии, отказов сетевого оборудования. Менее точно, но возможно «битый» диск, на котором расположена база.

II. Подготовительный этап

Перед выполнением работ:

  • закройте имеющиеся клиентские подключения к информационной базе (по-простому — «выгнать» пользователей, если таковые подключены);
  • обязательно , это очень важно — сделайте резервную копию базы , а лучше две и сохраните в разных местах, любым доступным способом (например, для файловой 1С — копирование всего каталога, основного файла 1Cv8.1CD или выгрузка в dt-файл через Конфигуратор).

III. Возможные действия по исправлению

  1. Проверка с помощью утилиты chdbfl.
  2. Тестирование и исправление (ТиС) в режиме Конфигуратора.
  3. Копирование ИБ в другое расположение.
  4. Выгрузка базы в dt-файл и загрузка в новую базу.
  5. Обновление платформы 1С.

Почему в такой последовательности? Приложение chdbfl проверяет и исправляет нарушения физической целостности, инструментарий «Тестирование и исправление» — внутренние ошибки (ссылочную и логическую целостность). Поэтому в первую очередь chdbfl, а потом ТиИ.

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

Читайте также: