В связи с тем, что объем таблиц для прихода и расхода увеличивается, расчет остатков стал длиться очень долго. Расчитываются остатки путем вычитания из прихода всего расхода. Не хотелось бы заниматься "резкой" таблиц по периодам, а м.б. поменять алгоритм или что нибудь еще...
Товары приходуются в упаковках, расходоваться же могут упаковками и штуками.
Пример выборки, которая и отрабатывает очень долго:
SELECT r.id,r.cnt,sum(IIF(e.log=0,e.cnt,0)) as e_cnt,sum(IIF(e.log=1,e.cnt,0)) as e_cnt_p,;
MAX(ALLTRIM(m.name)+IIF(ISNULL(p.name),'',' '+ALLTRIM(p.name))) as medname,;
MAX(r.retailprice) as retailprice,;
000000000000+MAX(IIF(n.countinpack=0,1,n.countinpack)) as cntinpack, r.barcode as barcode,MAX(r.apptyme) as app_tyme ,;
max(TTOD(d.date)) as date,'' as inv_no;
FROM receipts r,expenses e,documents d,medications m,nomenclatures n LEFT OUTER JOIN produsers p ON n.prod_id=p.id;
WHERE r.id=e.rcpt_id AND n.id=r.nom_id AND n.med_id=m.id AND d.id=r.doc_id AND d.closed AND d.store_id=goApp.nStoreHouse_ID AND d.closed;
GROUP BY r.id,r.cnt, r.barcode ;
UNION all;
select r.id,r.cnt,0 as e_cnt,0 as e_cnt_p,;
ALLTRIM(m.name)+IIF(ISNULL(p.name),'',' '+ALLTRIM(p.name)) as medname,r.retailprice,;
000000000000+IIF(n.countinpack=0,1,n.countinpack) as cntinpack, r.barcode as barcode,r.apptyme as app_tyme,;
TTOD(d.date) as date,'' as inv_no;
FROM receipts r,documents d,medications m,nomenclatures n LEFT OUTER JOIN produsers p ON n.prod_id=p.id ;
WHERE n.id=r.nom_id AND n.med_id=m.id AND d.id=r.doc_id AND d.closed AND d.store_id=goApp.nStoreHouse_ID AND d.closed;
AND NOT r.id in (select DISTINCT e.rcpt_id as id FROM expenses e );
INTO CURSOR _rest READWRITE
далее куски кода отрабатыват достаточно быстро. В них происходит:
REPLACE ALL e_cnt WITH cnt-e_cnt-CEILING(e_cnt_p/cntinpack),;
e_cnt_p WITH IIF(MOD(e_cnt_p,cntinpack)=0,0,cntinpack-MOD(e_cnt_p,cntinpack))

Flt_Expr=IIF(m.tlWithNull,'','WHERE e_cnt#0 OR e_cnt_p#0')
INSERT into rem_tg ;
SELECT id , medname as name, retailprice as price ,e_cnt as cnt,e_cnt_p as cnt_p,cntinpack,barcode,app_tyme,date,inv_no ;
FROM _rest &Flt_Expr &&WHERE e_cnt+e_cnt_p>0
USE IN _rest

luserПодвешивает фокс ?
Несколько не понял формулировки вопроса....
выгребается на данный момент около 10 секунд.
Фокс просто 10 секунд (если в отладке запускаю) не реагирует за события.

luserДумаю что и без отладки во время выполнения запроса реакции на события не будет. Ситуация распространенная при больших выборках, могу посоветовать выполнить запрос асинхронно, правда ля этого придется создавать COM-компоненту на VFP.
Не думаю, что асинхронный вариант что-то изменит, ведь проблема не в подвешивании. Народу ничего не нужно делать в момент выгребания данных и они нехотят ничего делать. Они хотят нажимать на кнопку и быстро получать результат...

AiSKСобственно говоря, а чего вы ожидали? Допустим вы соптимизируете запрос и вместо 10 секунд будете выполнять за 5, но с ростом таблицы приходов и расходов проблема будет только усугубляться.
Подход у вас довольно прямолинейный, вам бы следовало хранить текущие остатки товаров в отдельной таблице (регистре текущих остатков), плюс завести таблицы остатков на начало периодов (чтобы при исправлении, удалении, пересчете операций пересчет остатков начинать с начала периода, а не с начала всей таблицы). При этом резать таблицу по периодам нет необходимости.
Согласен, с тем, что при росте таблиц скорость будет падать! Проблема в том, что если я пойду по пути расчета остатков на периоды и тем самым сокращу размеры таблиц, то это приведет к переписыванию большой части кода другими программистами. Хранить остатки в отдельной таблице или в дополнительных полях детализации прихода накладно, т.к. они могут не совпасть с реальными (опыт был у знакомых программистов на InterBase+Delphi). Как вариант думаю, увеличит ли скорость если при загрузке программы я буду помечать расходы и приходы как полностью "исчерпавшие себя", т.е. остаток = 0? Незнаю как отразится на скорости, т.к. придется ведь всеравно вначале покрайней мере работать с "полными" таблицами! Как думаете?
Redrik
Т.е. у тебя народ при выписке товаров жмет кнопочку и эти остатки вычисляются "на лету"? Меняй алгоритм! На sql.ru море дебатов и советов...

Поможите направьте на алгоритм хотябы на пару ссылок!!!