в 1с писать лень. ибо скажут, мол, обновитесь до 8.5.***

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

ВЫБРАТЬ ПЕРВЫЕ 10
    Номенклатура.Код КАК код,
    Номенклатура.Наименование КАК Наименование
ПОМЕСТИТЬ ВТ_1
ИЗ
    Справочник.Номенклатура КАК Номенклатура

УПОРЯДОЧИТЬ ПО
    Наименование ИЕРАРХИЯ
;

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

Зацикливание иерархии

(0) а запрос ты руками набирал? емнип, конструктор не пропустил бы

(2) емнип = ип

(0)[хотелось бы объяснить данное поведение]
запасся попкорном =)

(4) умеешь же похоронить интригу(.

УПОРЯДОЧИТЬ ПО
    Наименование ИЕРАРХИЯ

Без этой штуки работает?

Свисток ...
....
ПОМЕСТИТЬ ВТ_1
......
УПОРЯДОЧИТЬ ПО

(7) с ПЕРВЫЕ можно
(6) проблема именно в ИЕРАРХИЯ

(8) в том то и беда, что проблем С ЗАПРОСОМ вообще нет (если прочитать (0) чуть внимательнее, то там это сказано.)

(0)
вот это дает сей эффект

ПОМЕСТИТЬ ВТ_1 //если это заремить, ошибки не будет

вот запрос. скрины прикладывать что-то не получается.

DROP TABLE #tt3

CREATE TABLE #tt3 (_Q_000_F_000 NVARCHAR(6) COLLATE DATABASE_DEFAULT, _Q_000_F_001 NCHAR(11) COLLATE DATABASE_DEFAULT, _Q_000_F_002 NVARCHAR(100) COLLATE DATABASE_DEFAULT, _Q_000_F_003RRef BINARY(16), _Q_000_F_004RRef BINARY(16))

exec sp_executesql N'INSERT INTO #tt3 WITH(TABLOCK) (_Q_000_F_000, _Q_000_F_001, _Q_000_F_002, _Q_000_F_003RRef, _Q_000_F_004RRef) SELECT TOP 10
P1,
T1._Code,
T1._Description,
T1._IDRRef,
T1._ParentIDRRef
FROM dbo._Reference62 T1
ORDER BY (T1._ParentIDRRef), (T1._IDRRef)',N'P1 nvarchar(4000)',N'111222'

select * from #tt3

(10) в (11) есть ПОМЕСТИТЬ ВТ_1

И ошибку дает не скуль..

(11) правильна, у тя тут нет иерархии, которая делается потом

(14) "у тя тут нет иерархии".ORDER BY (T1._ParentIDRRef)
поясни? я не понимаю.

(15) попутал с В..иерархии
Один хрен, вся ошибка в (10)  - заремь создание временной и 1с это прожуёт

(15) ORDER BY (T1._ParentIDRRef) это просто по родителю. Не по иерархии.

(16) а зачем тогда (0)?

(0)

Топикпстер:
-- Пацаны, смотрите! Прыгает в лужу -- летят брызги в виде слона.

Весь форум:
-- Угу.Угу. Не прыгай в лужу, а то будут брызги.
А еще лучше - вообще лужу обойди

(19) очень похоже.

Пишут что это старая ошибка и уже разок исправлялась https://forum-baza.ru/index.php?topic=64620.0

(21) в 10й пофиксили, в 25й вернули. всё по плану.

(22) не только, в 18 тоже падает.

(1) почему тогда без временной таблицы его нет?
(13) да. что-то я ошибку SDBL со скулёвой попутал. пардон.
зы:
не нашёл вменяемого объяснения, что делает платформа, когда иерархия во временной таблице.

+(24) запрос то уже выполнен. она работает с результатом (если я правильно понимаю).

(25) а если обернуть запрос в подзапрос?

(26) ага, робит.
ВЫБРАТЬ *
ПОМЕСТИТЬ ВТ_1
ИЗ
    (ВЫБРАТЬ ПЕРВЫЕ 10
        Номенклатура.Код КАК код,
        Номенклатура.Наименование КАК Наименование
    ИЗ
        Справочник.Подразделения КАК Номенклатура
    
    УПОРЯДОЧИТЬ ПО
        Наименование ИЕРАРХИЯ) КАК ВЛОЖ

но мне понятнее не стало.

(26) во вложенном нельзя ВТ.
это плохой пример, вопчим.

(22) А чё вы хотели? Количество возможных ошибок - величина не бесконечная. В какой-то момент приходится возвращать старые...

(28) а зачем во вложенном ВТ?

Все ошибки в платформе в общем исправили. Остались вопросики к запросам, которые за 15 лет так и ни разу не писал.