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

Вот мой запрос: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

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

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

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

Я нахожусь на VFP 9 sp2. Кто-нибудь знает, как ускорить его?

EDIT: Хорошо, позвольте мне обобщить и посмотреть, есть ли у кого-либо идеи.
Я создаю курсор с select into ... cursor cGift.
Затем я запускаю указанный выше запрос по указанному курсору.
Это быстро в командном окне, но очень медленно при запуске из формы.
Точный одинаковый код как для курсора, так и для запроса.
Я понятия не имею, какие настройки среды включены/выключены/wtvr в моей форме, так как это часть очень большой программы.

источник

2012-04-04 slicedtoad

ОК, я не мог понять, что было по-другому в двух окружениях, но я запросил запрос, изменив его и разбив на две части (что-то не так с движком 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

Объединение тех, делает все очень медленно.

источник

2012-04-11 13:46:59 slicedtoad

Но, похоже, вы тоже реструктуризировались. Я не удивлен, что запрос с производной таблицей будет быстрее, чем с проекцией. –

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

SET ANSI и/или SET EXACT
SET DELETED
множество индексов доступны (если вы на самом деле решение различных таблиц)
кодовой страницы и/или последовательность сортировки

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

Тамар

источник

2012-04-04 21:15:31

Я не уверен, какая кодовая страница/последовательность сортировки, но другие не работают, включая входы LAK. Индексация не должна быть проблемой, так как я создаю курсор прямо перед запросом, и это единственная таблица, которую использует запрос. Курсор создается точно таким же кодом как в командном окне, так и в форме. – slicedtoad

Это недостаток индексов, которые замедляют работу в обеих средах. (3 секунды для медленного запроса в мире VFP.) Что-то должно быть разным между двумя средами, чтобы дать вам разницу по величине. –

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

источник

2012-04-09 16:58:02 LAK

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

ответ

Смежные вопросы