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

1. в 1С?
2. зачем?

Нужно упорядочить по полю и получать ПЕРВЫЕ N записей ГДЕ поле > значение

для этого есть "выборка", это динамический обьект и он считывает информацию по мере необходимости

или я не так понял?

(1) В 1С. надо.

Тогда (2) и поле должно быть уникальным

(5) Не обязательно. Можно сделать условие ГДЕ поле > значение-1

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

и остаётся вопрос: зачем?

На мисте так сделано

(5) и не меняться в результате обработки выборки первых N записей. Иначе можно погрузиться в вечную выборку одного и того же :)

(3) Откуда считывает?

(0) Динамический список

(10) с сервера

Зачем-зачем. Есть внешний сервис, который дергает данные из 1С и делает нужное. Все 100500 записей разом ему не переварить, надо порциями.

1С так не умеет, она для динамических списков использует метод (2). ADO может что то похожее, называется AsyncFetch.

(12) Что за "сервер"? Судя по (0), ему хочется одним запросом к БД обойтись

(13) Пиши результат запроса в регистр, и пусть сервис потом дергает данные из регистра

(15) Наоборот, я могу обойтись запросом на каждый вызов. Но я не хочу каждый раз тащить все записи.

а обращаться к БД без 1с можно?
https://technet.microsoft.com/ru-ru/library/gg699618(v=sql.110).aspx

(12) на сколько я понимаю результат хранится на сервере во временных файлах и по мере обращения к конкретным полям выборки происходит чтение соответствующих областей временных файлов

(16) Из регистра записи тоже будут дергаться запросом. Тоже самое получится.

(20) Так в регистре будет срез всех данных на момент "большого" запроса. А потом уже порционное получение.

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

(21) В этом случае еще надо будет мутить обновление данных в регистре, ослежвание считанных-несчитанных… Геморно

(23) Так почему у тебя за один вызов сервиса идет получение данных в большем объеме, чем ты хочешь за этот вызов отдать?

(22) Видишь на главной мисты под списком тем циферки? Тык, получаю 20 записей, тык - следующие 20. При этом из базы тащится ровно те 20 записей, а не миллион. Вот такое мне надо, только в 1С.

(25) Попробуй пролистать дальше, поймёшь принцип

Просто в mysql есть LIMIT N, M

(25) Так это зависит от самих данных в таблице же.
Что такое "следующие 20" - это ровно те, что шли бы после предыдущего получения данных или любые 20, отличающиеся от первых? Таблица упорядоченная?

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

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

а если важно обработать все - то придется писать в базу "обработан"

(27) Просто он тоже тормозит, поэтому пришлось изобрести решение (2)

Блин, нельзя использовать ВЫБРАТЬ ПЕРВЫЕ &КоличествоЗаписей...

(31) Регистр сведений и свой курсор как душе угодно )

(32) это не stateless…

(33) Так что с (28)? Что будет "следующие N" с соблюдением твоего стейтлеса?

(34) А зачем вы вопросом на вопрос отвечаете?

Простейшая задача. Показывать на странице по 100 наименований из 25 000. Юзер ткнул в страничку, которая должна показать товар с 12700 по 12799.
Как? Не включая ненужные первые 12699 записей в выборку запроса?

ИМХО в 1С - только получив первые 12799. А потом из выборки забрав только последние 100.

можно и запросом

выбрать первые 100
(ВЫБРАТЬ ПЕРВЫЕ 1000 ..)
Упорядочить по Поле УБЫВ

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

(37) Ну слава богу. Я уж подумал, что выпал из реальности.

(37) не ужто ты раньше этого не знал?

(39) Знал. Хотелось меньшей кровью обойтись.

(35) "вопросом на вопрос отвечаете?" // Проспись что ли

Кстати, способ (2) подходит только для прохода в одну сторону. Для прохода в другую сторону надо менять параметры и условия. Для полноценного пагинатора (т.е. доступа к "странице" данных по номеру) этот способ не подходит.

Data commander 3 это умеет