ZarinaВсем спасибо за внимание и за советы.
А по-поводу последнего...
Игорь,я бы не морочила себе голову со всем этим потому как обьёмы таблиц не достигают такого как вы говорите,но ...
тут помимо этого есть другие причины.
Сервера не очень мощные на которых БД лежит ,плюс сеть такая же , в программе ну очень многов сяких расчётов (например в гриде идёт поиск по всеё таблице и расчёт) и по мере накопления -за несколько месяцев работы всё начинает ну настолько медленно работает , что хочется простьо застрелиться.Ну к примеру ходим Enter по Grid , по скорости я могла бы уже перейти на пятое поле а он только на второе перескочил.
Вот поэтому и морочусь.
А на это есть другие решения. Под общим названием "оптимизация".

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

Чтобы при простом переходе по полям был такой тормоз. Это надо очень постараться. Точнее, надо совсем не думать

ZarinaВладимир я очень рада за Вас,что Вы хорошо думаете!
Я бы попросила без оскорблений и намёков.
Если Вам нечего посоветовать то пожалуйста вообще ничего не говорите,по крайней мере мне!
Извините. Не хотел обидеть.

Просто, чтобы что-то советовать по поводу оптимизации надо знать, в чем причина такого тормоза при простом переходе по полям (записям) таблицы. ЭТО никак, никоим образом не может (точнее, не должно!) зависеть об объема базы данных. Если у Вас ТАКОЕ происходит - это наводит на не очень лестные выводы по поводу авторов кода.

Если уж совсем честно, то я вообще не вижу причин для обид. Посмотрите начало этого топика:
ZarinaЯ наверное ленивый программист,но...уж очень не хочется почему то думать,тем более,что один раз уже думала,но не получилось.

Я пока внимательно код не смотрел. Вечером посмотрю подробнее. На вскидку, есть очень много "тонких" мест в приведенном коде, очень плохо влияющих на скорость.

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

Есть ПЛАН (был введен ранее) и есть ФАКТ (который вводится сейчас в Grid). В процессе ввода ФАКТА надо рассчитать разницу (по некоему относительно сложному алгоритму) и отобразить ее в дополнительных столбцах.

ZarinaНу для того ,чтобы нормально понять код нужно знать задачу,а она очень специфическая.
Не обязательно. Т.е. да, желательно понимать то, что делаешь. Но есть целый ряд чисто формальных приемов (не зависящих от конкретной задачи), которые, например, я использую уже "на автомате". Я знаю, что так будет быстрее. В Вашем коде эти формальные приемы сплошь и рядом нарушаются.

ZarinaЯ вообще то сначала сделала через SELECT, но он почему то переодически плохо себя вёл: или считал неправильно,я так понимаю фильтр неправильно в нём отрабатывал ,или вообще давал 0.
Правда это был простой запрос ,а не с вложенным как вы написали - попробую ещё раз.
Правила сравнения символьных строк в "обычных" командах регулирует настройка SET EXACT, а в команде Select-SQL настройка SET ANSI. Эти настройки похожи по сути, но все-таки есть отличия. Особенно при использовании символов тождественного равенства. Что само по себе есть не очень хорошо.

Zarina1) А что SELECT быстрее работает чем CALCULATE ?
В общем случае, без разницы. Но есть ряд факторов, которые могут замедлить (или ускорить) как выполнение Select-SQL, так и CALCULATE. Т.е. надо смотреть по конкретной задаче.

Zarina2) А как можно проверить за сколько времени отработает запрос, т.е вот сейчас у меня CALCULATE и я хочу знать , сколько он работает,потом поменяю на SELECT и хочу посмотреть разницу во времени?
Делается большая тестовая таблица с огромным количеством записей (не менее миллиона). Запоняется всяким мусором и запускаются нужные команды. Причем надо запускать несколько раз, поскольку FoxPro умеет кешировать данные. Первый запрос, как правило, выпоняется медленне последующих.

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

Основа оптимизиации (здесь - ускорения) - это индексы. Нет индексов - нет оптимизации. Есть индексы - оптимизация возможна. Разумеется, кроме использования индексов есть и другие способы оптимизации, но все они на порядок медленнее, да и возможны в очень специфических случаях.

FoxPro не подерживает индексы с переменной длиной ключа. Т.е. если выражение индекса имеет вид AllTrim(MyField), то FoxPro, конечно, уберет ведущие пробелы, но затем самостоятельно (по собственной инициативе) добавит концевые пробелы до некоторой фиксированной длины.

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

А как же ведущие пробелы? А их надо отсекать принудительно на стадии ввода данных. Самый простой способ - это указать свойство Format = "T". Это не самый лучший способ, поскольку его можно обойти, но указание этого свойства на уровне свойств поля таблицы в 90% случаев вполне достаточно.

В результате, Ваше выражение фильтра

AllTrim(Fakt.idAkt)+AllTrim(fakt.idRec)==AllTrim(AktVRec.idAkt)+AllTrim(AktVRec.idRec)

Заменяется таким выражением

Fakt.idAkt=AktVRec.idAkt AND fakt.idRec=AktVRec.idRec

При этом я предполагаю:

1) Сравниваемые поля имеют одинаковую размерность (количество символов)
2) Ни в одной записи у этих полей нет ведущих пробелов
3) По каждому полю построен простой индекс в той сортировке (idxCollate()) в которой Вы собственно и работаете (SET COLLATE) в данный момент

При выполнении этих условий такое выражение фильтра будет оптимизировано (будут использовны индексы) и результат сравнения будет абсолютно идентичен первому выражению

Аналогично выражение фильтра

alltr(c_met)==alltr(lcmet) and alltr(proba)==alltr(lcproba)

Заменяется выражением

c_met=m.lcMet AND proba=m.lcProba

Разумеется, при формировании переменных m.lcMet и m.lcProba отсекать пробелы НЕ НАДО!

Кстати, сложение символьных строк подобным образом - это верный путь к ошибкам. Например:

"11"+"1" == "1"+"11"

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

=================
Вы используете для поиска команду LOCATE. Надеюсь, Вы в курсе, что активный индекс тормозит ее выполнение. Т.е. перед выполнение команды LOCATE следует сбросить главный индекс (потом можно его восстановить).

SELECT fakt
SET ORDER TO 0
LOCATE FOR ...

То же самое справедливо и для команды CALCULATE. При сброшенном главном индексе скорость ее выполнения резко повышается.

====================
Как уже заметили ранее, переход на запись по GO на порядок быстрее поиска по LOCATE. Т.е. для возврата на старую запись следует использовать команду

GO m.lnRecno IN fakt

====================
Приведенный код - это перерасчет в результате изменение содержимого одной (текущей записи). Логично было бы убедиться, что такое изменение имело место быть. А не просто переход из однойго поля (записи) в другое. Т.е. надо запомнить значение поля при входе (When) и сравнить со значением при выходе. Если есть отличия, то запускать эту процедуру проверки.

Промежуточное значение можно записать в свойство TAG. Оно есть у каждого объекта FoxPro и представляет собой просто текст комментария никак не влияющий на работу программы. Единственное ограничение - он имеет символьный тип данных.

====================
Из приведенного кода я не совсем понял - будет ли модифицировано после расчет только та же самая запись или возможна модификация и других записей таблицы. Если модификация затрагивает всегда только текущую запись таблицы, то нет смысла делать пересчет по всем записям. Надо просто вычесть из суммы старое значение и прибавить новое. Безо всяких дополнительных CALCULATE.

====================
Вы говорите, что на форме 2 грид "отфильтрованы по id документа и id записи". Не совсем понял, что Вы имеет в виду, но если речь идет о SET FILTER или SET KEY, то советовал бы отказаться от их использования в пользу параметризированных LOCAL VIEW.

В отличии от наложенных фильтров, процесс открытия LOCAL VIEW несколько замедленый, но зато потом в процессе работы с Grid - никаких тормозов. Для фильтров ситуация прямо противоположная - быстрое открытие, но постоянное "притормаживание" при перемещении по записям.

Использование LOCAL VIEW отменяют все выше изложенные ограничения для индексов (т.е. код можно оставить без изменений), поскольку LOCAL VIEW - это выборка (результат выполнения Select-SQL) в которой, разумеется, нет индексов. Поэтому оптимизаци невозможна в принципе. Конечно, если не построить эти индексы при открытии Local View. Но не думаю, что это оправдано в данном случе.

====================
Ну, есть еще замечания по стилю. Но это уже мелочи. На скорость принципиального влияния не оказывают. Чтобы оптимизировать код еще больше надо уже знать собственно предметную область. Что именно этот код делает и для чего. Все что я описал выше - это замечания, основанные на приведенном коде абсолютно без какой-либо связи с поставленной задачей. Те самые "формальные" правила.

ZarinaВы написали множество советов,в частности про команду LOCATE.
Вот у меня на столе лежит 4 книги по фоксу и не в одной не написаны подобные нюансы.
Скажите пожалуйста где можно почитать,посмотреть более глубоко и широко .
Может какие то конкретные источники посоветуете?
На самом деле, книги на такие нюансы и не рассчитаны. Теоретически, все это есть в стандартном HELP к любой версии FoxPro.

Например, открываете HELP по команде LOCATE и обязательно увидите ссылку на статью вроде " Optimizing Applications " или " Using Rushmore... " в том же Help. Да и раздел "See Also", тоже дает информацию к размышлению.

Проблема только в том, что все это в стандартном HELP "рассыпано" по многим статьям и "размазано" по разным разделам каждой статьи. Что, вобщем-то, и логично. Цель статьи - это сформировать некое целостное представление по рассматриваемой проблеме или команде, а не по конкретной задаче .

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

Впрочем, кое-какие попытки предпринимаются. Но они далеки от идеала именно в силу специфики задачи.