Внутренняя ошибка при реконструкции запроса
При обновлении версии с 3.0.27.10 на новые появился жуткий глюк.
"Анализ счета", "Обороты счета" вылетают с ошибкой.
Ошибка SDBL: Внутренняя ошибка при реконструкции запроса (2)
Информация о программе:
-----------------------------------------
Платформа: 1С:Предприятие 8.3 (8.3.4.389)
Конфигурация: Бухгалтерия предприятия, редакция 3.0 (3.0.28.13)
Режим: Серверный (сжатие: усиленное)
СУБД PostgreSQL
Приложение: Тонкий клиент
Вариант интерфейса: Версия 8.2
Ошибки:
------------------------------------------
16.01.2014 8:24:28
{ОбщийМодуль.ДлительныеОперации.Модуль(166)}: Ошибка SDBL:
Внутренняя ошибка при реконструкции запроса (2).
ВызватьИсключение(ТекстОшибки);
"Тестирование и исправление" со всеми галками - не помогает.
Кто подскажет как это лечит?
"Анализ счета", "Обороты счета" вылетают с ошибкой.
Ошибка SDBL: Внутренняя ошибка при реконструкции запроса (2)
Информация о программе:
-----------------------------------------
Платформа: 1С:Предприятие 8.3 (8.3.4.389)
Конфигурация: Бухгалтерия предприятия, редакция 3.0 (3.0.28.13)
Режим: Серверный (сжатие: усиленное)
СУБД PostgreSQL
Приложение: Тонкий клиент
Вариант интерфейса: Версия 8.2
Ошибки:
------------------------------------------
16.01.2014 8:24:28
{ОбщийМодуль.ДлительныеОперации.Модуль(166)}: Ошибка SDBL:
Внутренняя ошибка при реконструкции запроса (2).
ВызватьИсключение(ТекстОшибки);
"Тестирование и исправление" со всеми галками - не помогает.
Кто подскажет как это лечит?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Ну, коллеги, можно потихоньку тестировать новый релиз платформы, 8.3.4.428. Пока тестовый, но, вполне вероятно, станет стабильным.
Среди исправленных ошибок
20021752 ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита
Проблема:
В клиент-серверном варианте информационной базы с использованием СУБД PostgreSQL при выполнении запросов, содержащих ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита, являющегося разделителем, может происходить ошибка
Ошибка SDBL: Внутренняя ошибка реконструкции запроса (2).
и аварийное завершение работы программы.
Дата публикации:
2014-02-10
PS: Прошу прощения за оверквотинг.
Среди исправленных ошибок
20021752 ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита
Проблема:
В клиент-серверном варианте информационной базы с использованием СУБД PostgreSQL при выполнении запросов, содержащих ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита, являющегося разделителем, может происходить ошибка
Ошибка SDBL: Внутренняя ошибка реконструкции запроса (2).
и аварийное завершение работы программы.
Дата публикации:
2014-02-10
PS: Прошу прощения за оверквотинг.
не об этой ли ошибке идет речь?
20021752 ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита
Проблема:
В клиент-серверном варианте информационной базы с использованием СУБД PostgreSQL при выполнении запросов, содержащих ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита, являющегося разделителем, может происходить ошибка
Ошибка SDBL: Внутренняя ошибка реконструкции запроса (2).
и аварийное завершение работы программы.
Дата публикации:
2014-02-10
20021752 ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита
Проблема:
В клиент-серверном варианте информационной базы с использованием СУБД PostgreSQL при выполнении запросов, содержащих ПОЛНОЕ СОЕДИНЕНИЕ подзапроса и таблицы, входящей в состав общего реквизита, являющегося разделителем, может происходить ошибка
Ошибка SDBL: Внутренняя ошибка реконструкции запроса (2).
и аварийное завершение работы программы.
Дата публикации:
2014-02-10
(1) Jon2011, Абсолютно такая же ошибка на всех базах третьей бухгалтерии.
Попробовали даже с 8.3.4.408, один результат. Перевели базы на файловую версию, но это, не очень удобно, пришлось настраивать терминалы людям.
(17) strav, Если верить сайту users.v8.1c.ru, то ближайший релиз 8.3.5 состоится не ранее 27.02.14г. ))))) Да здравствуют новые баги!!!
Попробовали даже с 8.3.4.408, один результат. Перевели базы на файловую версию, но это, не очень удобно, пришлось настраивать терминалы людям.
(17) strav, Если верить сайту users.v8.1c.ru, то ближайший релиз 8.3.5 состоится не ранее 27.02.14г. ))))) Да здравствуют новые баги!!!
Проблему подтверждаю. Точно такая же ситуация: PostgreSQL 9.1.2, 1с 8.3.4.389.
ИТС предложили стандартные процедуры типа ТиИ, что, естественно, никак не помогло. Вышло обновление БП 3.0.28.14, поставил на закачку. Посмотрим, вдруг поможет (не слишком надеюсь). Анализ логов субд ничего не показал, т.к. при запросе на формирование карточки счета запрос до субд просто не доходит: глюк платформы или конфигурации.
Добавлю: есть 3 БД версии 3.0, и на всех эта проблема воспроизводится.
Мы не одиноки
ИТС предложили стандартные процедуры типа ТиИ, что, естественно, никак не помогло. Вышло обновление БП 3.0.28.14, поставил на закачку. Посмотрим, вдруг поможет (не слишком надеюсь). Анализ логов субд ничего не показал, т.к. при запросе на формирование карточки счета запрос до субд просто не доходит: глюк платформы или конфигурации.
Добавлю: есть 3 БД версии 3.0, и на всех эта проблема воспроизводится.
Мы не одиноки
(6) Rothschild, в списке ошибок, предназначенных к исправлению в 8.3.5, есть вот это:
30004062 (SW804101, SW805220) Запрос с более чем одно ПОЛНОЕ СОЕДИНЕНИЕ
Проблема:
В клиент-серверном варианте информационной базы с использованием PostgreSQL при выполнении запроса, содержащего более чем одно ПОЛНОЕ СОЕДИНЕНИЕ, может происходить ошибка
Ошибка SDBL: Внутренняя ошибка при реконструкции запроса (1)
и аварийное завершение работы программы.
Дата публикации:
2013-11-20
Наверное, не оно (у нас, как минимум, Ошибка SDBL: Внутренняя ошибка при реконструкции запроса (2)).
Но похоже.
30004062 (SW804101, SW805220) Запрос с более чем одно ПОЛНОЕ СОЕДИНЕНИЕ
Проблема:
В клиент-серверном варианте информационной базы с использованием PostgreSQL при выполнении запроса, содержащего более чем одно ПОЛНОЕ СОЕДИНЕНИЕ, может происходить ошибка
Ошибка SDBL: Внутренняя ошибка при реконструкции запроса (1)
и аварийное завершение работы программы.
Дата публикации:
2013-11-20
Наверное, не оно (у нас, как минимум, Ошибка SDBL: Внутренняя ошибка при реконструкции запроса (2)).
Но похоже.
(9) Jon2011, Сдается мне, тут дело не в PostgreSQL. я в (5) приводил ссылку, процентов на 99 уверен, что у них там MSSQL. Если бы кто из владельцев MSSQL попробовал.
У меня 9.1.2 64-битная, на CentOS 6.5, собрана из src.rpm. 9.2.4 сырая еще, тут были обсуждения, решили, что "нуего", будем ждать 9.3.
У меня 9.1.2 64-битная, на CentOS 6.5, собрана из src.rpm. 9.2.4 сырая еще, тут были обсуждения, решили, что "нуего", будем ждать 9.3.
В файловой базе все работает нормально. Временно подключил бухам нужные базы в файловом режиме, потом затащу обратно на сервер. А что делать, людям работать надо.
ИТС молчит как рыба об лед. Значит, ждем 8.3.5?
ИТС молчит как рыба об лед. Значит, ждем 8.3.5?
(15) А у Вас какая СУБД, если не секрет? Интересно просто, эта проблема только с PostgreSQL, или и с MSSQL/Oracle тоже.
По теме. Вчера пришло письмо с настройками техжурнала, попросили воспроизвести проблему и прислать выхлоп лога. Сделал. Передали разработчикам.
Вышедший вчера релиз конфигурации (багфикс) 3.0.28.15 проблему, естественно, не решил.
По теме. Вчера пришло письмо с настройками техжурнала, попросили воспроизвести проблему и прислать выхлоп лога. Сделал. Передали разработчикам.
Вышедший вчера релиз конфигурации (багфикс) 3.0.28.15 проблему, естественно, не решил.
20.01 написал в техподдержку 1С письмо с этой ошибкой, сегодня получил ответ:
А вот где взять эту версию не сказали ;-(
Коллеги, это проявление ошибки платформы 30004062.
Ошибка проявилась в релизе платформы 8.3.4.365
Ошибка исправлена в версии 8.3.5.263
Ошибка проявилась в релизе платформы 8.3.4.365
Ошибка исправлена в версии 8.3.5.263
А вот где взять эту версию не сказали ;-(
У них кругом проблемы:
В связи с проведением технических работ на сайте в период с 10-00 24.01.2014 по 10-00 27.01.2014 (по московскому времени) не будет работать регистрация программных продуктов пользователей. Приносим извинения за доставленные неудобства.
Получился временный обход:
Если в свойствах конфигурации поставить совместимость с версией 8.2.16.
В модулях отчетов заменить ЭтотОбъект на ЭтаФорма.
То "Анализ счета", "Обороты счета" и др. работают нормально и с 8.3.4.389
Остальное, естественно, надо тестировать самим ;-)))
P.S. эта ошибка зарегистрирована под номером sw819598
Если в свойствах конфигурации поставить совместимость с версией 8.2.16.
В модулях отчетов заменить ЭтотОбъект на ЭтаФорма.
То "Анализ счета", "Обороты счета" и др. работают нормально и с 8.3.4.389
Остальное, естественно, надо тестировать самим ;-)))
P.S. эта ошибка зарегистрирована под номером sw819598
(23) strav, уже на первом этапе реструктуризации система выдала около 30 предупреждений. Тем не менее я продолжил загрузку. При запуске базы, журнал с приходными доками не открылся сославшись на ошибку в форме документа. Отчет по 41 счету завис намертво. После этого я снес эту глупость и больше к ней не возвращался.
Нормально, чо. Сейчас обновил БП до 3.0.29.7. На клиент-серверном варианте Анализ счета и Обороты счёта всё то же, причём по всем счетам:
Оборотно-сальдовые ведомости работают без ошибок.
{ОбщийМодуль.ДлительныеОперации.Модуль(166)}: Ошибка SDBL:
Внутренняя ошибка при реконструкции запроса (2).
ВызватьИсключение(ТекстОшибки);
Внутренняя ошибка при реконструкции запроса (2).
ВызватьИсключение(ТекстОшибки);
Оборотно-сальдовые ведомости работают без ошибок.
(33) FractalizeR, И как себя показывает DB2 для 1С? Мы его просто даже не пробовали. А судя по тому, что его рассматривают как временную замену для PostgreSQL, то его и использовать не стоит?
(34) Jon2011, Наши не смогли пережить... А т.к. они всё-таки ближе к начальству, чем любой админ, то сидят уже на файловой версии.
(34) Jon2011, Наши не смогли пережить... А т.к. они всё-таки ближе к начальству, чем любой админ, то сидят уже на файловой версии.
(42) Jon2011, Да, ушла. Правда, у меня Бухгалтерия 3.0, а не Торговля. Вчера поставили, пока полет нормальный. Все, что не работало из-за проблемы с реконструкцией запроса - заработало.
(43) strav, v9.7 FP6, на тот же сервер с 1С: Предприятие из дистрибутива с сайта 1С. У меня там Postgres стоял, все было нормально. Сервер - двойной Xeon, SAS в RAID. Это не из-за нагрузки. Что-то не так с настройками, полагаю.
(43) strav, v9.7 FP6, на тот же сервер с 1С: Предприятие из дистрибутива с сайта 1С. У меня там Postgres стоял, все было нормально. Сервер - двойной Xeon, SAS в RAID. Это не из-за нагрузки. Что-то не так с настройками, полагаю.
(45) strav, А что будет если db2 запустить на 2Gb памяти? И какая у вас конфигурация 1С и сколько пользователей, что для комфортной работы требуют для себя 6Gb оперативки только под SQL??? Просто у нас на резервных серверах по магазинам в 3Gb оперативки успешно влазит CentOS, PostgreSQL и сервер предприятия 1С. При этом на Комплексной автоматизации и 6 пользователях всё летает. Винт - обычный sata.
(46) JusteRU, Будет тормозить ;-))
db2 V9 express не может использовать больше 2GB памяти, CPU: 1 sockets, 2 cores
db2 V10 express может использовать до RAM: 16GB, CPU: 1 sockets, 2 cores
Экспериментальным путем для своей базы и количества пользователей (15чел) остановились на 6Gb памяти под db2, 1С отдельно на 4Gb. Все на CentOS 6.5 в виртуалках. Конфигурация БП30 3.0.29
db2 V9 express не может использовать больше 2GB памяти, CPU: 1 sockets, 2 cores
db2 V10 express может использовать до RAM: 16GB, CPU: 1 sockets, 2 cores
Экспериментальным путем для своей базы и количества пользователей (15чел) остановились на 6Gb памяти под db2, 1С отдельно на 4Gb. Все на CentOS 6.5 в виртуалках. Конфигурация БП30 3.0.29
(47) strav, Это было временное решение пока ошибка реконструкции была или постоянно на DB2 сидите?
Есть опыт когда БД в виртуалке на CentOS 6.5 + 8Gb + PostgreSQL успешно держит 50 пользователей УТ11.0. Правда там совсем не 2 ядра, а очень даже 12. При таком раскладе смысла в DB2 не вижу совсем.
Есть опыт когда БД в виртуалке на CentOS 6.5 + 8Gb + PostgreSQL успешно держит 50 пользователей УТ11.0. Правда там совсем не 2 ядра, а очень даже 12. При таком раскладе смысла в DB2 не вижу совсем.
Postres отличная вещь, но, похоже, что внутреннее тестирование в 1С выполняют только на SQL Server :) Выпустить обновление и не увидеть, что стандартные отчеты, которыми нормальые бухи каждый день пользуются, перестали работать....
Нашёл тут письмо от 1С:
О необходимости замены версии 8.3.4.428 платформы "1С:Предприятие"
Всем пользователям, установившим версию 8.3.4.428 платформы
"1С:Предприятие", необходимо ее заменить на другую версию. Рекомендуется
перейти на версию 8.3.4.408.
Фирма "1С" просит партнеров, установивших клиентам версию 8.3.4.428,
оперативно заменить ее на указанную выше версию.
В версии 8.3.4.428 платформы "1С:Предприятие" обнаружена критичная
ошибка, возникающая при реструктуризации данных. Данная ошибка
локализована и будет исправлена в следующей версии платформы.
О необходимости замены версии 8.3.4.428 платформы "1С:Предприятие"
Всем пользователям, установившим версию 8.3.4.428 платформы
"1С:Предприятие", необходимо ее заменить на другую версию. Рекомендуется
перейти на версию 8.3.4.408.
Фирма "1С" просит партнеров, установивших клиентам версию 8.3.4.428,
оперативно заменить ее на указанную выше версию.
В версии 8.3.4.428 платформы "1С:Предприятие" обнаружена критичная
ошибка, возникающая при реструктуризации данных. Данная ошибка
локализована и будет исправлена в следующей версии платформы.
(67) JusteRU, если требуется только Бух запустить, я считаю нужно ставить 428.
При тестировании базовых релизов было все хорошо и 1С готова была сделать ее текущим обновлением, но видимо новые релизы не проходят реструктуризацию, поэтому они и забраковали ее.
Для себя решил, буду сидеть на 428, но новые релизы для Бух, УТ11 и ЗУП ставить не буду пока не выпустят новую платформу.
При тестировании базовых релизов было все хорошо и 1С готова была сделать ее текущим обновлением, но видимо новые релизы не проходят реструктуризацию, поэтому они и забраковали ее.
Для себя решил, буду сидеть на 428, но новые релизы для Бух, УТ11 и ЗУП ставить не буду пока не выпустят новую платформу.
(75) FractalizeR, Вот и думай, что приводит к этой ошибке и появится ли она у нас... В 8.2.18.какой-то было так, что РИБ не выгружались совсем.
(73) FractalizeR, (74) Jon2011, У них, похоже, и правда нет нормального стенда для тестирования конфигураций. И даже на те грабли, которые они наступали, они наступают снова.
(73) FractalizeR, (74) Jon2011, У них, похоже, и правда нет нормального стенда для тестирования конфигураций. И даже на те грабли, которые они наступали, они наступают снова.
(77) strav, вышел тестовый 8.3.4.437, при желании можете его попробовать. Тем более, что 8.3.5 откладывается.
(75) FractalizeR, +1, обновил 30 с гаком типовых БП 2.0, 4 типовых БП 3.0 и несколько ЗУП 2.5 уже под 428-м релизом, ничего вроде как не вылезло. Может, как-раз таки хвост вытащили - голова увязла: на PostgreSQL все ОК, а на M$SQL - опаньки. Хоть бы эти 1с - овцы писали, где оно проявилось.
Добавил: О как, вот, кажется, оно вылезает Мдаа....
(75) FractalizeR, +1, обновил 30 с гаком типовых БП 2.0, 4 типовых БП 3.0 и несколько ЗУП 2.5 уже под 428-м релизом, ничего вроде как не вылезло. Может, как-раз таки хвост вытащили - голова увязла: на PostgreSQL все ОК, а на M$SQL - опаньки. Хоть бы эти 1с - овцы писали, где оно проявилось.
Добавил: О как, вот, кажется, оно вылезает Мдаа....
(82) strav, тоже вчера поставил 437-й. Деться все равно некуда. На предложение откатиться назад народ отреагировал бурно, не стесняясь цветистых выражений, даром что женщины.
PS А FractalizeR говорит, что у 1С нет бета-тестеров. Вот взять хотя бы эту ветку - уже человека 3-4 есть :-)
PS А FractalizeR говорит, что у 1С нет бета-тестеров. Вот взять хотя бы эту ветку - уже человека 3-4 есть :-)
(84) FractalizeR, (85) strav, (86) Bukaska, Дык ото-ж! Причем особенно приятная эта чехарда с прыжками с версии на версию, когда люди делают отчетность и на все перестановки 6-7 ночных часов. И кроме 1С еще есть чем заняться.
Хотя это не только у 1С. Везде такой, как бы помягче сказать. Бардачина.
У нас основной канал интернета 4 дня лежал, причем не только у нас, наверное, у полгорода, у кого АДСЛ этого провайдера. Машинисты-трактористы (ну вы поняли, кто) упорно молчали, типа "все нормально, это у вас проблемы, перезагрузите модем". Потом уже выяснилось, что у них то ли сегмент упал, то ли в другой ЦОД сервера переносят. Предупредить по-человечески - не, мы ж великие.
Если бы не резервный канал - все, пиши пропало. Издержки монополизма. Впрочем, что и хорошо: теперь резервный канал стал основным, а трактористам - 300 руб в месяц (белый IP не хочется терять). Гуляйте, хлопцы. Так сказать, голосование рублем.
По теме: как я понимаю, 437-й релиз стал стабильным, в нем рассматриваемая ошибка устранена. Ура, товарищи? Проблема решена всего за три с половиной месяца.
Хотя это не только у 1С. Везде такой, как бы помягче сказать. Бардачина.
У нас основной канал интернета 4 дня лежал, причем не только у нас, наверное, у полгорода, у кого АДСЛ этого провайдера. Машинисты-трактористы (ну вы поняли, кто) упорно молчали, типа "все нормально, это у вас проблемы, перезагрузите модем". Потом уже выяснилось, что у них то ли сегмент упал, то ли в другой ЦОД сервера переносят. Предупредить по-человечески - не, мы ж великие.
Если бы не резервный канал - все, пиши пропало. Издержки монополизма. Впрочем, что и хорошо: теперь резервный канал стал основным, а трактористам - 300 руб в месяц (белый IP не хочется терять). Гуляйте, хлопцы. Так сказать, голосование рублем.
По теме: как я понимаю, 437-й релиз стал стабильным, в нем рассматриваемая ошибка устранена. Ура, товарищи? Проблема решена всего за три с половиной месяца.
(87) audion, Буквально вчера стал стабильным, и, если через пару дней его снова не отменят, будем радоваться =)
Сроки реакции, конечно, поражают, но и не настолько плачевны. Неделю 437й релиз в работе, каких-либо проблем в тонком и толстом клиентах найдено не было. Обновление баз проходит на ура.
Сроки реакции, конечно, поражают, но и не настолько плачевны. Неделю 437й релиз в работе, каких-либо проблем в тонком и толстом клиентах найдено не было. Обновление баз проходит на ура.
(73) FractalizeR, команда бета-тестеров - это похоже только мы. У них элементарные ошибки переходят из версии в версию. Например обмен между УТ11-Бух30 уже в третий раз не идет. Приходится опять в ручную состыковывать.
Причем, тех.поддержка знает как эту задачу решить, а в базовую версию почему-то изменения не попадает.
Причем, тех.поддержка знает как эту задачу решить, а в базовую версию почему-то изменения не попадает.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот