Привет!

Имеем подключение к SQL серверу FireBird через ODBC с использованием сквозных запросов.
Как можно в VFP выполнить серию запросов след. образом:

1. Послать запрос на сервер (SQLExec или препаре - не суть), пуская он его молотит ....
2. Что-то поделать (обработать данные пред. запроса, подготовить какие-нибудь базочки и т.д.)
3. Получить от сервера результаты запроса (курсор).
4. Послать следующий запрос...
5. Обработать результаты первого ...
6. Послать следующий ...
7. Обработать рез. второго ...

и т.д.

Что-то я не никак не разберусь как надо использовать для этого SQLPrepare(), SQLExec(), SQLMoreResults() или что-то еще.

С уважением Панов А.Ю.
ООО "Такт" г.Сызрань

Итак, после детального исследования механизма асинхронного выполнения SQL запросов можно сделать следующие выводы:

1. При выполнении Res=SQLExec(nConnect,'Select ....','Result') в асинхронном режиме VFP дожидается выполнения запроса полностью и поступления первой порции данных (т.е. начала фетча записей), после чего управление передается программе и далее при вызове очередного Res=SQLExec(nConnect) принимает очередную порцию данных (у меня по 100 записей).

2. Таким образом во время обработки запроса на сервере программа все равно простаивает. :((( А мне хотелось использовать это время для обработки других данных. У меня как раз и были "тяжелые" группировочные запросы, возвращающие небольшие курсоры.

3. Отсюда следует, что асинхронность выгодна при выполнении запросов не связанных с группировкой или сортировкой данных (GROUP BY, ORDER BY в запросах), а при длительных и тяжелых фетчах, когда записи выбираются медленно, в промежутках между поступлением записей можно что-то поделать.

4. Если после первого SqlExec() обратиться к полученному курсору (например спросить Reccount), то VFP все равно закачает все записи и пойдет дальше.

Вот так!

С уважением Панов А.Ю.
ООО "Такт" г.Сызрань.

Привет, Владимир!

>Что-то у Вас какие-то странные выводы получились.

Выводы на основе эксперимента по Вашей схеме. А Вы сами пробовали ? Скорее всего у Вас были простые запросы без группировки или сортировки.

Вот код (проверки на ошибки и прочие "фантики" опущены):
---------------------------------------------------
LOCAL lnRes,lnCount,lтConnect

=SQLSetProp(lnConnect,'Asynchronous',.T.)

lnRes=SQLExec(lnConnect,'SELECT ... FROM ... GROUP BY 1','TestRes')

* Здесь пауза порядка неск. сек (пауза естественно зависит от запроса)

lnCount=0
DO WHILE lnRes=0
WAIT WIND 'Запрос выполняется '+str(lnCount,5) NOWAIT
lnRes=SQLExec(goIB.nConnect)
lnCount=lnCount+1
ENDDO
------------------------------------------------------------

Так вот после подачи первой SQLExec имеем паузу - это выполняется запрос (счетчик в цикле не мелькает), а вот когда замелькал счетчик это пошел фетч, видно как записи увеличиваются в статусной строке. Этот же запрос я проверял в стороннем инструменте там точно такая же пауза перед началом фетча.



>Асинхронный запрос именно потому так и называется, что его выполнение распаралелено с прочими процессами в FoxPro.

Я тоже так думаю. Сервер молотит запрос, FoxPro может делать другую работу.

>1. С какой стати ему ждать ПОЛНОГО выполнения запроса?

Вот-вот я тоже так считаю.

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

>-) Fox послал инструкцию на сервер и стал выполнять прочие операции не ожидая окончания выполнения этой инструкции

Видимо все-таки ждет.

>-) Поступление очередных порций результата никак не завязано на факт подачи команд SQLExec(). Процесс-то асинхронный. Какое отношение имеет к нему прочие команды?

Т.е. вы хотите сказать, что если я "прочие команды" буду выполнять достаточно долго (допустим повешу MessageBox и буду ждать пять минут), то после подачи последнего и одного SqlExec() у меня в курсоре будет сидеть вся выборка? Это я и хотел бы получить, но что-то не выходит или "в консерватории что-то поправить"

>-) Периодическая подача команды SQLExec() необходима для проверки состояния в котором находится выполнение асинхронного запроса. Если возвращает 0, то асинхронный запрос все еще выполняется. Все. Никакого другого "тайного" смысла в этой команде нет.

При выполнении очередного SqlExec() почему увеличивается счетчик кол-ва записей в курсоре, а без оного не желает, из чего я и сделал вывод, что SqlExec фетчит очередную порцию.

>-) Объем очередных порций данных регулируется настройкой CursorSetProp('FetchSize',...)

Это понятно.

>2. Нет, в процессе выполнения асинхронного запроса программа не простаивает. Скорее всего, Вы просто некорректно построили саму программу, вынуждая ее к простою.

См. выше усе как Вы и советовали.

>3. Опять неправильный вывод

Возможно.

>4. А вот с Reccount() как раз правильно. Но вовсе не потому о чем Вы подумали. Просто в процессе выполнения асинхронного запроса значение Reccount() непрерывно меняется и Fox не в состоянии прочитать его значение из заголовка временной таблицы до окончания процесса. Вот он и ждет пока процесс завершиться. Т.е. фактически Вы переходите в режим синхронного запроса.

Собственно я так и понял и даже не спорю.


>Кроме того, необходимость в асинхронном запросе возникает, только если результат выполнения инструкции имеет значительный объем, или время выполнения этой инструкции очень значительно.

>В первом случае, возникает резонный вопрос: а зачем качать с сервера такую кучу информации? Т.е. у Вас крайне непродуманная идеология.

Около 1000 записей содержащих движение по товару это разве "куча".

Идеология как раз продуманная и качаем только то что нужно, а не для того чтоб было.

>Во втором случае следует отсылка к оптимизатору запросов. Вимдимо очень некорректно составлен сам запрос.

Ну уж не знаю, что может быть некоректного в выборке движения товара за определенный период, посредством запроса SELECT T.Wkod,SUM(T.Quan) FROM T WHERE T.DateDoc>='01.04.2003' and T.DateDoc<='30.04.2003' GROUP BY 1

Запрос конечно упрощен, там есть еще неск. join, но они все оптимизированы т.е. выполняются при помощи индексов.

Давайте не заострять внимания на составлении запросов. Если будут вопросы по этому - спрошу отдельно. Для начала разберемся с асинхронностью.

С уважением Панов Алексей Юрьевич
ООО "Такт" г.Сызрань.

Проверил еще раз, уже в командном окне.

Имеем таблицу на FireBird 1.5 RC6 330 тыс записей.


Подаю ? SqlExec(1,"SELECT Wkod,SUM(Quan) FROM ExpL GROUP BY 1")

Возникает пауза порядка 6 секунд, затем отображается значение ноль и идет счетчик записи.
Если не дождаться остановки счетчика записей, ? SqlExec(1) выдает ноль. Если дождались, то 1.

Я согласен со всеми твоими выводами, кроме паузы возникающей после первого SqlExec().

Я думаю, что пауза возникает не из-за величины запроса, а из-за свойств SQL-сервера или ODBC драйвера.

>PS: Если в результате у тебя всего 1000 записей, то стоит ли заморачиваться с асинхронными запросами?

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


Спасибо за ответы.

С уважением Панов Алексей.
ООО "Такт" г.Сызрань.

PS: А что у тебя за задача, в которой используешь VFP и MS SQL, а то в конференции по FireBird, VFP монстром обозвали и сказали нерационально его использовать для Sql-Сервера.

>Да, вероятнее всего задержка связана именно с ODBC. Но все-равно, мне кажется, что эта задержка не следствие выполнения чего-то там на самом сервере, а следстве затрудненности собственно передачи инструкции на сервер. Т.е. в твоем случае эти 6 секунд запрос "пропихивается" через ODBC

Попробовал дать ? SQLExec(1,'SELECT Wkod FROM ExpL WHERE Wkod=12345')
Запрос возвращает одну запись, ответ последовал мгновенно. Т.е. дело не в отправке запроса на сервер.

> Или через одну хранимую процедуру (не знаю, есть ли такие в FireBird)

Угадал, раньше так и было, все запросы обрабатывались в ХП, но возникли непредвиденные проблемы с ODBC драйвером, не могущем разруливать уровни изолированности транзакций (FireBird версионник), т.е. два юзера не могли одновременно воспользоваться процедурой. Поэтому сейчас тупо переделываю на посылку серии запросов. (Пойми правильно это не проблема FireBird, там технология позволяет одновременно использовать процедуру хоть тысяче пользователей).

>Скорее всего, тот кто это сказал наткнулся на невозможность использования в VFP какого-то подхода к которому он привык в другой среде.

Опять угадал (ты случайно не телепат ли) именно так и сказали, "трудно совместить навигационный подход VFP с технологией Sql".

> Например, мне очень нравится в FoxPro такая вещь как макроподстановка, но в других языках программирования этого или в принципе нет, или ее реализация крайне затруднена. А это значит, что придется использовать совсем другой стиль программирования. Кому же это понравится :)

Совершенно верно.


С уважением Панов Алексей.
ООО "Такт" г.Сызрань

Ну во первых у нас разные сервера и как следствие разные ODBC. Поэтому корректно сравнивать как мне кажется не получится.

Настройки посмотреть без проблем, только вот какие и где (я не сисадмин поэтому в настройках сетей разбираюсь плохо).

С уважением Панов Алексей.
ООО "Такт" г.Сызрань