1. Выполняется запрос к MSSQL и затем читается через RecordSet.
2. Чтение происходит на сервере 1С.
3. Чтение происходит порциями(!).

Нужно сохранить указатель RecordSet между серверными вызовами.

В обычных формах проблем не было - сохранил в переменной и все работает.

В УФ средствами 1С - никак (ВремХранилище + Структура(RecordSet) - не предлагать).

Единственный вариант - чтобы указатели сохранялись в самом SQL.

Вопрос знатокам: есть ли такая возможность?

SQL-сервер принципиально работает с наборами данных, а не с отделными строками. Вы требуете с него слишком многого.

(1) курсор и есть набор отдельныз строк, требования не к сиквелу, а к хранению контекста ADODB на стороне клиента

Если результат запроса монотонно упорядочен, то можно сохранить последнее значение ключа, по которому произведена сортировка, а при следующем запросе добавить условие, чтобы ключ был больше этого значения. Так работает динамическое чтение списков в 1С.

(2) Курсор работает "на стороне сервера". Это его внутренняя процедурная обработка. Клиенту будет выдан набор данных.

(3) увы, в общем случае не подходит.

(1) по сути я его и прошу работать с набором.. просто нужно понять как можно обращаться к одному и тому же набору, без возможности сохранения указатели на клиенте

А что насчет общих модулей с повторно возвращаемыми значениями?

(6) Нет у него "указателя". Есть только ключ записи. Только он идентифицирует запись. Его и ищите и на него позиционируйтесь.

(8) имею ввиду указатель на текущую запись.

1 вызов серверной процедуры: выполнил запрос SQL,получил рекорд сет, прочитал N записей
2. вызов серверной процедуры: прочитал следующие N записей из РекордСет-а

на ОФ было так...

(8) да понял, не правильно формулирую. Сохранять мужду вызовами нужно не указатель, а сам объект RecordSet

(10) Может стоит все прочитать, загнать в ТЗ и, уже из нее читать порциями? Зачем нужно порциями непосредственно из рекордсета?

(9) а кто мешает к скулю подключиться с клиента?

+(12) или ты с планшета подключаешься?

(11) это уже сделано, и хочется еще ускорить. Перегон РекордСета в ТЗ - занимает ощутимое время

(12) с клиента нет доступа к SQL

(0) Используй нечто внешнее относительно 1С

А еще лучше http://v8.1c.ru/overview/Term_000000795.htm

(17)+ Отдельную конфу 1С на сервере которая работает с MSSQL как с внешним источником.
В ней поднят веб или http сервис.
Из своей основной конфы хоть с сервера хоть с клиента хоть пока по http соединяешься с отдельной и как хочешь хоть целиком хоть порциями получаешь.

И не морочь уже голову некрофилией

(18)+ Имхо я бы микросервис на golang (бэк обычный же по rest) за пару часов сваял.
Простой exe'шни в итоге который после запуска работает как веб-сервер на нужном порту, принимает запросы от 1С по http и работает с MSSQL.

А это идея!

Хотя не верю что еще нет транслятора sql запросов по http в MSSQL сервер и получение обратно по http результата.

(19) Я загнул про пару часов, часа за глаза ибо https://github.com/besser/go-mssql

(15) СОМ объект тебе недоступен? Им прекрасно можно к скулю подключаться

(14) Можно сохранить не в ТЗ, а во "временную" таблицу SQL, с первичным ключом в виде числа. Затем выбирать (3). В конце очистить.
(22) Если клиент веб браузер или находится в интернете с медленным каналом, то как достучаться до SQL?

(23) пожалуй вариант!

(23) Вариант с "временной таблицей" слегка изврат, и предвижу кучу глюков.
Например дважды 1С запрос в двух сеансах тот же делает и что?

(25)+ Имя таблицы по идентификатору сеанса или еще чего из 1С?
Или еще один ключ в таблицу и очищать только свои?

(0) гуглим OFFSET-FETCH

(26) Временная таблица своя для каждого сеанса

(26) временные таблицы вполне в рамках 1 сеанса, а вот глобальные временные -одни на всех