Индекс не найден

[Irina_]

Здравствуйте. Пишу отчет на vip. Столкнулась со следующей проблемой.
В Create view указываю в качестве главной таблицу SUMVIDOP с индексом SUMVIDOP01 по CLSCH + YEARK + MES + VIDOPL.
Накладываю условие G1 == SUMVIDOP.YEARK,
где G1 – параметр из интерфейса ввода параметров формирования отчета.
Компиляция прошла без ошибок, но при запуске отчета на формирование получаю ошибку:
«Индекс не найден. В таблице SUMVIDOP.».
В чем причина ошибки? Ведь указанный индекс у таблицы есть.

[Dmitry_Sol]

Добрый день. В Идексе который вы указали, YEARK идет вторым сегментом. Это значит, что сначала индексируется первый сегмент - ссылка на лицевой счет, а затем уже YEARK. Вам нужно или, сначала указаать ограничение по лицевому счету, или использовать другой индекс, где YEARK идет первым сегментом. В этой таблице это SUMVIDOP14

Успехов

[Irina_]

SUMVIDOP14 не подходит, т.к. мне нужна сортировка сначала по л/сч, потом по месяцу ЗА который. А в указанном индексе сортировки по л/сч нет.

[Dmitry_Sol]

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

Код: Выделить всё

G1 == SUMVIDOP.YEARK (noindex)

все равно на скорость отчета существенно это уже не повлияет

Успехов

[edward_K]

Условие вы накладываете через PushBounds или все таки AddBounds?
Первое вызывает попутку выбрать данные с другим индексов.
в bounds еще есть ключ ordered by tableorder
А для AddBounds лучше всегда писать noindex.
Насколько вообще вам необходимо подымать на ходу ограничение?
еще можно в (()) после последнего ограничения на вашу таблицу написать

Код: Выделить всё

 and (G1=0 or G1 = SUMVIDOP.YEARK)/code] 
Писать нужно именно в (( )) - в этом случае ограничение будет только SUMVIDOP.

[Irina_]

To Dmitry_Sol.
Я не совсем поняла фразу ‘если вы уверены, что у вас уже наложено индексное условие по лицевому счету’. Таблица SUMVIDOP у меня главная, мне нужно взять из нее данные за нужный год по всем л/сч, которые там встретятся, правда не по всем ВО. Поэтому о каких ограничениях по л/сч Вы пишите? Я накладываю только одно ограничение на указанную таблицу – на год.
Наложила условие на год как неиндексное, ошибка пропала. Буду еще смотреть, что же выбралось в отчет и правильно ли.
Исходник выкладывать не буду, т.к. только сегодня закончила писать, еще не дошло до отладки.

To Edward_K.
Ограничение указываю в (( )), и на эту таблицу оно одно.

[Den]

Вообщем, условий на lschet никаких нет во вью )
у вас это отчет лучше сразу на dsql написать запрос с какой угодно там сортировкой и избавиться подбора нужного индекса
А так можно еще попробовать SUMVIDOP07 , если не смутит сортировка по месяцам

[edward_K]

В общем под этот индекс одно условие G1 == SUMVIDOP.YEARK не пойдет - вам об этом и написали
Если вы говорите, что вам важна сортировка по лиц.счетам, правильней тогда добавить в запрос Lschet и сканировать по нему. а внутри уже по SUMVIDOP.
А про вложенные запросы в курсе? Можно прям во from подсчитать сумму. И вообще в зарплате лучше сразу писать на DSQL если вам не нужна каждая строка в SUMVIDOP в отдельности - как вам получение отчета за год в разрезе видов оплат на базе под 20000 сотрудников за минуту?

[Irina_]

To Den.
Мы пока на 8.10, приведенного Вами индекса не нашла. И на dsql не писала. Отчет непростой, несколько лет назад писала на FoxPro, сейчас решила переписать на vip для удобства.

[Den]

У вас Irina_ какая платформа то ?

[edward_K]

Код: Выделить всё

(( ..   and lschet.Nrec == Sumvidop.cLsch and g1 == Sumvidop.Yeark ... ))
_loop Lschet
  _Loop Sumvidop 
....

[Irina_]

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

To Den.
У нас SQL.

To Edward_K.
Я посчитала, что в данном конкретном отчете правильно главной сделать Sumvidop, а не Lschet. Ведь меня интересуют начисления, без привязки к дате приема/ увольнения в л/сч.

[Den]

все равно придется задействовать lschet иначе только на внешней выгрузке


Ну можно тогда сделать попробовать как то так. Частичный вариант....

Код: Выделить всё

table struct MyLschet
(
 nrec :comp
);
interface Report_By_Sumvidop;
 create view
   var
  ...
  from 
    MyLschet
  , sumvidop (SUMVIDOP01)
  where ((
               MyLschet .nrec == Sumvidop.clsch
             and G1 = SUMVIDOP.YEARK
           ...
            ));

...
   СmInit:{
              sql select distinct clsch as nrec from sumvidop where yeark=:(G) into MyLschet byName;
              ....
            }

end.

[edward_K]

Считать вы можете все что угодно, но если во from указываете индекс, то и условия должны соотв. этому индексу - иначе ваша ошибка. Можно Order by поля - но если в логе компиляции будут сообщения о внешней выгрузке, то отчет будет работать очень долго. Опыт показывает, что иногда быстрее выгрузить во временную таблицу с нужным индексом ( через insert ... select ), чем пытаться подобрать сортировку в основном запросе, да и работать будет шустрее, поскольку сие делается одним запросом к серверу.

[Irina_]

Здравствуйте. Большое спасибо всем за советы. В результате остановилась на наложении условия
G1 == SUMVIDOP.YEARK (noindex).
Сначала в отчете не получила то, что надо. Были найдены мои ошибки ))). Сейчас все получилось.