Берем запрос "SELECT спр.ID [Номенклатура $Справочник.Номенклатура] FROM $Справочник.Номенклатура спр"
В профайлере наблюдаем exec _1sp_SC84_ByID по 1 на каждую строку.
На больших выборках тормозит нереально. Тоже самое без типизации выполняется на раз.

Вопрос. Есть ли способы чтоб типизация выполнялась одним запросом, а не по одному на каждую строку?

че то ты не то наблюдаешь

(1) Да как не то.... когда то. 2 серванта на обоих сабж.

(1) На больших выборках, на больших!

А по справочнику никто не лазит в это время? Он не открыт у тебя?

(0)Дибо глаза, либо руки.

Это именно в в момент выполнения или дальнейших действий?

(0) есть такая лажа

(4) Сижу один. Справочник закрыт.
(5) Ну я хз... что можно не так сделать?
(6) Когда запрос выполняется, сразу. В профайлере до и после спокойно. Только во время выполнения.

Переходите на 2005, какие фишки 2008 реально используются? :)

Наверное при БОЛЬШИХ 1С начинает что-то ворочать в кишках, вот и происходит перебор.

А если не делать выборку в ТЗ, а поместить во временную таблицу?

(9) Проверяю.

(9) а с какого ей чего-то ворочать?
как вариант только - переотрисовывать справочник, если открыт.
или если ТС результирующую ТЗ просматривает - получать представление.

(9) а нахрена типизация во временной?

глВыполнитьЗапрос(глБДЗапрос,"IF OBJECT_ID(N'tempdb..#ВВВВВ', N'U') IS NOT NULL DROP TABLE #ВВВВВ");
    глВыполнитьЗапрос(глБДЗапрос,"SELECT top 10000
    |спр.ID [Номенклатура $Справочник.Номенклатура]
    |INTO #ВВВВВ
    |FROM $Справочник.Номенклатура спр
    |");
    
    Рез = глВыполнитьИнструкцию(глБДЗапрос,"SELECT * FROM #ВВВВВ");
    Рез.ВыбратьСтроку();    


Собственно всё тихо до Рез.ВыбратьСтроку();

на 2000-м тоже самое происходит

(13) интересно, что ты хочешь иметь во временной таблице?
см (12)

Анафига типизировать при помещении во временную таблицу? О_о

(15,16) Абсолютно незачем, но ради спортивного интереса.

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

а нафига поиск по коду, если ты по ID через MetaDataWork можешь ссылку вытащить?

просто не понятна логика
сначала делаем красивую быструю выборку 1с++, а потом делаем тупой медленный найтипокоду?

Логика такая. Вот пришло время подбор запилить. А в нём остатки и прочая лабудень расчитывается при скролле. В скуле это жутко медленно. При открытии кидаю в тз и при скролле тупо ТЗ.НайтиЗначение.... я ж как думал... всё, тз на клиенте, к серверу по каждой строке обращаться - моветон. Но как оказалось по объектным типам данных к серверу всё одно есть обращения.  Зацепился на код. Поиск по коду идет быстро и на сервере тишь. Можно конечно для объектных переложить на sqlite и подготовить запросик табличка то в памяти сидеть будет, не жалко. Но то что получилось быстрее DBF, да и ладно.

(0)
путаете.
лавина  _1sp_SC84_ByID будет наблюдаться при отображении тз.

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

(22) Вот для этого и предложил во временную таблицу писать
(21) Нормально там все если не очень сложные расчет
У меня считались остатки, резервы, временные резервы, резервы под раскладку (все через юнион алл), средний сервер, 100 юзверей

> Собственно всё тихо до Рез.ВыбратьСтроку();
не, ну а ты чего ждал, собственно?

А хочешь хорощих, годных подборов - кури ТабличноеПоле

(25) Не ну тут можно его успокоить... в реальной работе 1С же будет искать по строке, а не показывать ТЗ полностью
К тому же можно в индексированную ТЗ выгружать и сделать индекс

(26) я не хочу успокаивать, а хочу чтоб дошло :)

(25) Ну как бы да.

Попробуй что получается по итогу, ее же не будешь показывать пользователям и тормозить не будет :)

(29) Эх... Ваша правда. Всему виной, вино и опиум ))... При отладке табличку подглядывал ))