Возьмем и сделаем рутину со следующим текстом:

&sql(declare cur CURSOR for select ID, Name, Home

from Sample.Person order by ID asc)

&sql(open cur)

&sql(fetch cur)

&sql(close cur)

q

Скомпилируем и сохраним текст полученной int-рутины. После чего изменим рутину следующим образом:

&sql(declare cur CURSOR for select ID, Name, Home

from Sample.Person order by ID desc)

&sql(open cur)

&sql(fetch cur)

&sql(close cur)

q

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

Запускаем SQL Manager и для проверки что действительно создана таблица sql и содержит тестовые данные, выполняем запрос

select ID, Name from NameList.

Если все было в порядке, то будет показана табличка с двумя колонками и десятком строк. Имена англоязычные, вымышленные. Для проверки работы прокрутки в обе стороны создадим рутину (например FetchBack) с кодом

n ascHandle,descHandle,ascSelect,descSelect,

n ok,i,AtEnd,Row,ID,Name,State,ascClose,descClose

; первоначальноевыражение - "select ID, Name from NameList"

; чтобы ходить по нему, преобразуем в два

s ascSelect="select ID, Name from NameList order by ID ASC"

s descSelect="select ID, Name from NameList order by ID DESC"

S ok=##class(%DynamicQuery).SQLPrepare(.descHandle,descSelect)

S ok=##class(%DynamicQuery).SQLExecute(.descHandle)

s descClose=descHandle

S ok=##class(%DynamicQuery).SQLPrepare(.ascHandle,ascSelect)

S ok=##class(%DynamicQuery).SQLExecute(.ascHandle)

s State=$li(ascHandle,1)

s ascClose=ascHandle

; идемна 4 шагавперед

s $li(ascHandle,1)=State

w "4 steps forward",!

f i=1:1:4 d

. d ##class(%DynamicQuery).SQLFetch(.ascHandle,.Row,.AtEnd)

. q:(AtEnd=1)!(Row="")

. s ID=$li(Row,1)

. s Name=$li(Row,2)

. w "ID="_ID_", Name="_Name,!

s State=$li(ascHandle)

; возвращаемся на 2 шага назад

s $li(descHandle,1)=State

w "2 steps backward",!

f i=1:1:2 d

. d ##class(%DynamicQuery).SQLFetch(.descHandle,.Row,.AtEnd)

. q:(AtEnd=1)!(Row="")

. s ID=$li(Row,1)

. s Name=$li(Row,2)

. w "ID="_ID_", Name="_Name,!

s State=$li(descHandle)

; снована 4 шагавперед

s $li(ascHandle,1)=State

w "4 steps forward",!

f i=1:1:4 d

. d ##class(%DynamicQuery).SQLFetch(.ascHandle,.Row,.AtEnd)

. q:(AtEnd=1)!(Row="")

. s ID=$li(Row,1)

. s Name=$li(Row,2)

. w "ID="_ID_", Name="_Name,!

s State=$li(ascHandle)

d ##class(%DynamicQuery).SQLClose(.ascClose)

d ##class(%DynamicQuery).SQLClose(.descClose)

q

Компилитуем, выполняем. В моем случае это выглядит как

4 steps forward

ID=1, Name=Presley,Samantha H.

ID=2, Name=Quine,Keith G.

ID=3, Name=Jones,Elvira A.

ID=4, Name=Townsend,Howard D.

2 steps backward

ID=3, Name=Jones,Elvira A.

ID=2, Name=Quine,Keith G.

4 steps forward

ID=3, Name=Jones,Elvira A.

ID=4, Name=Townsend,Howard D.

ID=5, Name=Uberoth,Juanita D.

ID=6, Name=Van De Griek,Michael K.

Видим, что два использованных запроса гладко сшились по используемому состоянию. Это обусловлено тем, что оба запроса совершенно идентичны за исключением направления сортировки. Исследование кодов возврата функций позволяет сделать суждение о более правильном отношении к закрытию запросов.

Таким образом, составить новый класс или набор классов, аналогичные по интерфейсу штатным, не составляет особых проблем. За исключением того, что имея один запрос мы должны будем сделать из него два. Для этого введем некоторую некрасивость - в теле запроса потребуем указания обеих сортировок и разделителей, ограничивающих собственно запрос и сортировки. Выберем в качестве разделителя символы $$$ и будем полагать, что запрос строится по схеме:

select ...

from ...

where ...

$$$ order by ... asc

$$$ order by ... desc

И что при этом программист возьмет на себя интеллектуальную работу по повторению сортировки в обоих концах. Поля, попадающие в сортировку, должны действительно определять строку выборки. Если поля в выборке допускают неуникальные строки, то следует ввести поле, введение которого сделает строку уникальной. Это требуется для корректного сшивания сортировок. Впрочем, это достаточно поверхностное теоретическое суждение и после его проверки оно может оказаться неверным в каких-то версиях.

Все, что нам понадобится, это удерживать в одном запросе два описателя вместо одного. При создании запроса сконструируем два объекта и при выполнении операций будем обращаться к соответствующим нашим внутренним объектам и передавать их данные штатному sql-движку.

Внимание привлекает поведение функций доступа, например, класс %DynamicSQLQuery, функция Fetch:

n %qref,rtn Set %qref=$lg(qHandle,1),rtn=$lg(qHandle,2)

Quit:%qref=""!(rtn="") $$$ERROR($$$GeneralError,"Query not Prepared")

QUIT $$Fetch^@rtn

Как видно по тексту, сама функция принимает и передает qHandle по ссылке, но к сгенерированной рутине обращается, передавая значения через локальные переменные. Код сгенерированной рутины закрыт, но судя по тому, что состояние qHandle должно быть передано наружу, ее модифицировать может только вызываемая рутина $$Fetch^@rtn. Других проблемных моментов я не нашел, поэтому к делу.

Экспортируем классы %DynamicQuery, %DynamicSQLQuery и $ResultSet в cdl. Дописываем к их именам символ 2 и правим коды так, чтобы у %DynamicSQLQuery2 была внутренняя поддержка обратной прокрутки, более развернутого хендла, чтобы у класса %DynamicQuery использовался запрос типа %DynamicSQLQuery2 и чтобы класс %ResultSet2 имел еще одну функцию, обращающуюся к FetchBack.

Получившиеся у меня для Cache' 4.1.9 классы можно загрузить по ссылке в конце страницы.

Проверочный код примерно следующего вида:

n result,i

Set result=##class(%ResultSet2).%New("%DynamicQuery2:SQL")

Do result.Prepare("select ID, Name from NameList

$$$ order by ID ASC $$$ order by ID DESC")

f i=1:1:4 d

. Write result.Get("ID"),result.Get("Name"),!

f i=1:1:2 d

. Write result.Get("ID"),result.Get("Name"),!

f i=1:1:4 d

. Write result.Get("ID"),result.Get("Name"),!

q

В результате его работы в терминале выдаются примерно следующие данные:

1Presley,Samantha H.

2Quine,Keith G.

3Jones,Elvira A.

4Townsend,Howard D.

3Jones,Elvira A.

2Quine,Keith G.

3Jones,Elvira A.

4Townsend,Howard D.

5Uberoth,Juanita D.

6Van De Griek,Michael K.

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

К неприятностям метода можно отнести следующие обстоятельства -

Использование нестандартного набора классов

Но что мешает изменить штатные классы, если это очень нужно?

Использование нештатной sql конструкции

Но штатной нет, а какая разница, какие символы будут там написаны? Все равно ведь что-то писать надо будет.

В версии Cache 5 появился дополнительный класс %ScrollableResultSet, который примерно то же самое и делает, и кроме того объект этого класса может быть сохранен в базе данных. Это позволяет просто организовать подкачку страниц например для веб интерфейса - выдачу строк порциями с сохранением контекста запроса между обращениями к базе например.