запрос vfp намного быстрее в командном окне, чем скомпилированный

Вот мой запрос:

SELECT solGroup,;
       SUM(IIF((;
                SELECT COUNT(*) FROM cgift c2;
                    WHERE c2.solgroup != c1.solgroup AND c1.donor == c2.donor;
                ) > 0;
           ,1,0));
        countgaveother;
    FROM cgift c1;
    GROUP BY solGroup

cGift — это курсор, содержащий список записей.

autonumber...donor....solGroup
1............10.......a
2............11.......a
3............10.......b
4............15.......b
5............10.......c
6............15.......c
7............11.......d
8............11.......d
9............16.......d

Запрос генерирует следующее

solGroup.."count of donors who have records with a different solgroup as well as this one"
a..........2
b..........2
c..........2
d..........1

В cGift около 80к записей (и еще много полей, которые здесь не используются). Запуск этого запроса (плюс запрос, создающий курсор) из командного окна vfp занимает 3 секунды, а из скомпилированной формы — 30 минут.

Кто-нибудь знает, почему разница в производительности так велика? Обычно окно команд работает очень похоже на мои скомпилированные формы. Другие запросы также прекрасно работают в этой форме.

Курсор создается с помощью select ... into cursor cGift. Его заказывает донор, хотя его удаление ничего не меняет.

Я на VFP 9 sp2. Кто знает как ускорить?

РЕДАКТИРОВАТЬ: Хорошо, позвольте мне подвести итоги и посмотреть, есть ли у кого-нибудь еще какие-либо идеи.
Я создаю курсор с помощью select into ... cursor cGift.
Затем я запускаю вышеуказанный запрос для указанного курсора.
Это быстро в командном окне, но очень медленный при запуске из формы.
Точно такой же код и для курсора, и для запроса.
Я понятия не имею, какие параметры среды включены/выключены/wtvr в моей форме, так как это часть очень большой программы.


person DanielST    schedule 04.04.2012    source источник


Ответы (3)


Чем отличается приложение от командного окна? Вот некоторые возможности:

  • УСТАНОВИТЬ ANSI и/или УСТАНОВИТЬ ТОЧНЫЙ
  • НАБОР УДАЛЕН
  • набор доступных индексов (если вы действительно обращаетесь к разным таблицам)
  • кодовая страница и/или последовательность сопоставления

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

Тамар

person Tamar E. Granor    schedule 04.04.2012
comment
Я не уверен, что такое кодовая страница/последовательность сопоставления, но другие не работают, включая входные данные LAK. Индексирование не должно быть проблемой, так как я создаю курсор прямо перед запросом, и это единственная таблица, которую использует запрос. Курсор создается с помощью одного и того же кода как в командном окне, так и в форме. - person DanielST; 10.04.2012
comment
Отсутствие индексов замедляет работу в обеих средах. (3 секунды для запроса — это медленно в мире VFP.) Между двумя средами должны быть какие-то различия, чтобы вы также получали разницу на порядок. - person Tamar E. Granor; 11.04.2012

Я согласен с тем, что это, вероятно, что-то о вашей среде командного поля по сравнению со средой вашей исполняемой программы. Я бы добавил состояние SHARED/EXCLUSIVE таблиц и/или настройку SET('EXCLUSIVE') в список вещей, которые нужно проверить.

person LAK    schedule 09.04.2012

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

SELECT *;
    FROM cgift;
    LEFT JOIN;
         (select donor donor2, count(distinct solgroup) activesols from cGift group by donor);
    b ON cgift.donor = b.donor2 INTO CURSOR cgift

Затем я считаю, где activesol> 1

Их слияние делает все очень медленным.

person DanielST    schedule 11.04.2012
comment
Но, похоже, вы тоже перестроились. Я не удивлен, что запрос с производной таблицей будет быстрее, чем запрос с проекцией. - person Tamar E. Granor; 12.04.2012