Галактика в вопросах и ответах

Добрый день!
Мне нужно в отчет вытащить данные из таблицы OTPUSK, отсортированными по полю DATAN.
Делаю так:
.....
.create view fo
as select otpusk.*
from otpusk(OTPUSK04)
where ((otpusk.cfactotpusk==factotpusk.nrec)) and 0<factotpusk.cplanotpusk and 1=otpusk.kotpus
!order by otpusk.datan
bounds bfo = ltabn==otpusk.tabn
;
.....
fo.pushBounds(fo.tbbfo);
ltabn:=NNNN;
.....
.{ table 'fo' by fo.otpusk.datan
.....
.}
.....

Сортирует упорно по NREC.
Проблема в том, что когда оформляют отзыв из отпуска в середине периода, то запись в таблице OTPUSK корректируется (причем меняется именно поле DATAN), и следом формируется еще одна запись, относящаяся к началу отпуска, и в результате получается что сначала выводится запись о второй половинке разбитого отпуска, а потом о первой. Не могу это победить.

Если делать просто запрос(без отчета) с сортировкой
order by otpusk.datan, то все отрабатывает красиво. Но мне надо в отчете.

Попробуйте через таблицу в памяти, с соответствующим индексом по дате

хе. Если вы подымаете bounds по tabn тогда уберите индекс из from. Нужный порядок бы я заложил бы в bounds - choice,tabn,datan, ну и фильтр соответсвующий.

Индекс я вставила уже от безысходности, без него тоже не работало...
Если пишу
.create view fo
as select otpusk.*
from otpusk
where ((otpusk.cfactotpusk==factotpusk.nrec)) and 0<factotpusk.cplanotpusk and 1=otpusk.kotpus
bounds bfo = 0<<=otpusk.choice and ltabn==otpusk.tabn and date(0,0,0)<<otpusk.datan
;
ругается компилятор, что нет такого индекса.

условие << может быть только на последнее поле. А что просто архивные не пойдет? 3 == otpusk.choice. Если нет то придется завести переменную и перебирать в ней значения 0,3,5.

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

ну вы сначала попробуйте с choice =3 - чтобы понять что вы не так делали. А потом уж во времянку выбирайте. вообще в вашем случае можно обойтись совсем без bounds а уловия перенести в where - все равно вы по табельному всегда отбираете - так оно надежней будет.

Вы хотите сказать, что торетически вариант из первого письма должен работать, что ошибка где-то чуть глубже?
Дело в том что изначально отчет работал не по OTPUSK, а по FACTOTPUSK, там поля по-другому называются, но суть та же, и все работало. Потом выяснилось, что по таблице FACTOTPUSK не отслеживаются отзывы в середине периода, вот и пришлось переделывать. Казалось бы, переделки незначительные, а сортировка перестала работать.

ошибка в том что вы намешали bounds order и index в одном флаконе.

На самом деле изначально был только bounds, все остальное - эксперименты. Но спасибо за науку))), я таких нюансов не знала.