.Create view vBook as select bookprzk.*, schfact.nrec, schfact.tipuser
where ((nSchFact == SchFact.nRec)) and
((((SchFact.nRec = BookPrZk.cSchFact) and
((schfact.tipuser = 7200) or (schfact.tipuser = 7300))) or
((SchFact.nRec = BookPrZk.cSchFacts) and
((schfact.tipuser) = 7217 or (schfact.tipuser = 7317)))));
но выборка из нее происходит слишком долго.
Помогите оптимизировать.
ну вот это
SchFact.nRec == BookPrZk.cSchFact
можно однозначно перенести из фильтра, по поводу поля tipuser, тут уже ни как, либо вообще отказаться от него
но думаю такая подцепка SchFact.nRec == BookPrZk.cSchFact даст немного прироста времени
.Create view vBook as select bookprzk.*, schfact.nrec
where
((
nSchFact == SchFact.nRec and // 1
SchFact.nRec == BookPrZk.cSchFact // 2
))
;
Может я что-то не допонял... Зачем tipuser проверять? По переменной подвязывается нужная счёт фактура. Если бы // 1 не было тогда понятно, а так как запись уже определена, получается совсем непонятно использование фильтров...
Max_Fin может я чего не понял, а может не так объяснил.
Дело в том что создается таблица, для выбора из нее других данных, например bookprzk.sum.
Выбираются все платежи из книги покупок или продаж соответствующие определенной СФ, по которой формируется отчет. Так вот все бы ничего, но если это "СФ отгрузка", то для ссылки на СФ используется поле bookprzk.cschfact. А если это "платеж по СФ", то используется поле bookprzk.cschfacts. Разница в один символ.
Ну дык, для этого и используются две таблицы
BookPrZk.POLE
BookPrZkSyn.POLE
ссылки на них глянь
тока поправь подцепки на двойные "==", малость недописал