А началось это здесь: Как избавиться от подтверждений на удаление и т.п., или что лучше DoCmd.Run (C) Sfagnum & Co.\r
\r
С одной стороны я часто встречал мнение неискушенных разработчиков (к каковым и отношусь сам), что выполнение запросов в асинхронном режиме волшебным образом увеличивает скорость выполнения программы в целом. Это ерунда. За мотивацией с моей стороны обращайтесь в указанное выше место, т.е. туда, откуда это всё началось :)\r
\r
С другой стороны, встречаю мнения продвинутых (в уважительном, хорошем смысле слова) разработчиков, исповедующих только синхронные режимы (утрирую).\r
\r
Сам долгое время считал асинхронные запросы аля "от лукавого", но узнав, что с самого начала разработки в Access я пользуюсь именно такого рода режимом выполнения запросов при открытии форм, стал относиться к этому чуду с меньшим страхом :) и с большим интересом. Опустим рассмотрение всех прелестей выполнения запросов в асинхронном режиме при открытии форм (ибо это стандартное, встроенное средство), а обратимся непосредственно к теме: \r
\r
"Сознательное (!) использование асинхронных запросов"\r
\r
1) С отображением данных вроде как всё ясно - асинхронный режим оправдан.\r
\r
2) А что на счет выполнения исполняемых (не селектов) запросов?\r
Смоделируем ситуацию... Сразу оговорюсь, что некоторые пункты избыточны, но в данном случае чем их (пунктов) больше, тем более понятна идея.\r
\r
На основе введенной Оператором приходной накладной должны быть выполнены следующие бизнес-транзакции:\r
а) Приходная накладная должна быть сохранена как документ;\r
б) Позиции в накладной должны быть сохранены как "расшифровка" суммы по документу;\r
в) Сама сумма должна быть учтена в соответствующих бухгалтерских проводках;\r
г) Должно быть пересчитано сальдо по взаиморассчетам с данным поставщиком;\r
д) товар должен быть распределен в соответствующие секции Склада;\r
е) товар должен быть распределен по логическим партиям, например по сроку годности (скажем товар относительно скоропортящийся и требует очень жесткого управления запасами - если годность поступившего товара исткает раньше, чем годность остатков этого же самого товара, то во-первых отделу закупок по шапке, а во-вторых надо сначала продавать именно новую партию, а уже затем остатки);\r
ж) автоматически сформировать Отпускные накладные по товару, закупленному "под заказ", т.е. по транзитному товару;\r
з) сформировать Отборные листы для склада (с указанием секций склада и логических партий товара) на основе Отпускных накладных;\r
и) уведомить какой-нибудь отдел о данном событии...\r
к) ну пожалуй и хватит!\r
\r
Предположим, что фирма большая и, соответственно, объемы данных огромны, а вот реализовано всё на... Аксе :) Пусть будет так!\r
В связи с выше сказанным, предположим, что выполнение всех этих действий займет 2 минуты +/- еще 10 минут :)\r
Еще одно немаловажное, а вернее САМОЕ ВАЖНОЕ допущение - Оператор занят только оприходованием накладных и, таким образом, не использует результаты своего труда - все те данные, которые были им введены не учавствуют в его дальнейших действиях.\r
\r
Ну и если это всё реализовать СИНХРОННО, то оператор после введения накладной может попить кофе, покурить и пойти погулять, а на все притензии своего начальства ткнуть в вас (программера) пальцем и сказать, что это система виновата, что работа не сделана! Что он, дескать, вынужден тупо чего-то ждать и ну не как не может начать оприходование следующей накладной, пока красная (зеленая/фиолетовая) "лампочка" на системном блоке "мигает". Кстати, это абсолютно реальная ситуация. Более того, я был "внутри" данной ситуации! Правда, не в качестве программера, но это не меняет суть - у работников появляется классная отмазка, а у тех, кто действительно работает, появляется раздраженность на тормоза.\r
\r
Реализуем эту же задачу АСИНХРОННО. Млин... Сказка какая-то! Не успел Оператор нажать соответствующую кнопочку, как документик закрылся (после небольшой задержки, связанной с некими внутренними подготовительными манипуляциями) и уже может начинать вбивать следующий документ! \r
Как же реализована эта "сказка"? Во как...\r
Создаем Класс (только в модулях класса можно использовать WithEvents) "ОприходованиеНакладных". Создаем некое ядро (в терминологии ЛП) или попросту "шагалку" (принцип описан в FAQ Сжатие БД, пункт 6.4) в которой в последовательном порядке выполняем необходимые действия, ключевыми из которых являются исполняемые запросы, запускаемые в асинхронном режиме. "Шагалка" переходит на следующий этап выполнения Оприходования накладной по соответствующему событию завершения выполнения асинхронного запроса. Т.е. мы создали... МНОГОЗАДАЧНОСТЬ! :) Код, обслуживающий Юзера крутится отдельно, а наш отдельный "поток" вызывается событиями завершающихся асинхронных запросов, в результате запускается очередной запрос и опять ожидается (без малейшего расхода машинного времени) его завершение! Ну точно отдельный поток получили!\r
\r
Косяк, конечно, есть и здесь - время оприходования накладной будет зависить от скорости работы Оператора, т.е. сам запрос будет выполняться по большей части только в моменты, когда Юзер "не шлет системе сообщений", т.е. не топчет клавиатуру и не катает мышку. В перерывах, так сказать... Т.е. в конечном счете выполняться это будет 10 минут +- еще 20! Для Оператора эта схема хороша, а вот для фирмы в целом - х.з., зависит от скорости проистекающих на фирме процессов.\r
Но всё равно, в этой идее что-то есть! То ли от "лукавого", то ли от... Хорошего, вообщем :)\r
\r
Что думаете, уважаемые, по поводу СОЗНАТЕЛЬНОГО использования асинхронных запросов в целом и о выше сказанном в частности?

Свидетель Geo, ваши показания приняты, но не поняты :)
Так в своем (обвинительном или оправдательном?:) повествовании вы сказали:
>таймер успеет отработаться n раз, и посчитает m% от нашей задачи. И некий отчет, требующей длительной подготовки и расчетов, откроется "мухой"
Соглашусь, но это касается только (!) случаев программной обработки некой задачи, а если же для выполнения данной задачи необходимо выполнить запрос, который отрабатывает секунд за 10? И таких запросов штук 10? Ну тока не надо говорить о неправильно выбранной среде разработки или структуре данных! Это ж просто размышления :) В этом случае выполнить запрос "кусочками", пока пользователь чешет промеж лопаток :), может только сама система! Да, по таймеру запустится запрос, но если он будет запущен в синхронном режиме, то пока не отработает фик пользователь увидит эхо от своих действий. Единственный выход организации "параллельной" работы кода и запроса – асинхронное выполнение последнего.
Именно поэтому ваши показания: "Т.е. асинхронные запросы не вредны (как, впрочем, и не необходимы), они просто есть. А могли бы и не быть." не принимаются к рассмотрению и будут вычеркнуты из протокола
Асинхронные исполняемые (не селекты) запросы однозначно нужны. Нужны они в одном-единственном случае – когда коду, который его запускает, не нужны результаты выполнения данного запроса.
На счет асинхронных "селектов" и так всё ясно :)

Тем не менее, вариант "таймерной многозадачности" принимается как механизм создания сверх-виртуальной многозадачности при решении задач средствами кода (не запросов). Спасибо!

> Так, чем придумывать какие-то "таймеры", почему бы…
Чё та я торможу :( В описанной мной гипотетической задаче разве можно что-либо сделать в момент открытия?

Нда... Саныч, сервер... Клиент-сервер... Мне об этом мечтать тока остается :( или второй комп покупать :) //не хочет ставить локальный сервак, хотя надобы...

Ну, вобщем-то, решение суда в отношении асинхронных запросов в mdb и еже с ним технологий (настольная и файл-серверная БД) однозначно:
1) Асинхронное выполнение селектов есть хорошо.
2) Асинхронное выполнение исполняемых запросов оправданно в случаях, когда коду, который его запускает, не нужны результаты выполнения данного запроса.
3) В многоПРОЦЕССОРНЫХ системах.
Решение может быть обжаловано :)

В отношении клиент-серверных технологий...
Показания свидетелей были однозначны:

Владимир Саныч:
>Между прочим, некоторые недостатки асинхронного запроса улетучиваются, если он исполняется на сервере

Вадя:
>и снхронность / асинхронность необходимо рассматривать уже несколько по другому. как настояющую асинхронность - 2 или более процессора (в контексте клиент-серверной технологии)

Geo:
>Или когда этому коду есть еще чем заняться, а запросы выполняются на другом компьютере

Оправдан! (ДЫМЦ) //удар молотка ...или как там эта штука называется?

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

Geo, не, твое:
>И, если запрос выполняется здесь же, на этом же компьютере, и здесь же лежат данные (не надо дожитаться, пока они доползут по сетке) - наоборот, важно, чтобы коду больше нечего было делать, иначе выползет 11-я секунда :)
не катит :)~
Я тут тестировал кое-что и специально создал табличку на 2,500,000 записей. Так знаешь чего? Локально она у меня прогружалась (полностью) порядка 50 секунд! Комп, конечно, тормознутый, но такие запросы только в асинхронном режиме, имхо, если конечно удовлетворены требования данного суда :) См. начало этого поста...

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

Гео, не, это я плохо спать буду :) В смысле мало, но рассказать ближнему то, что сам знаешь – дело хорошее, ибо откликнется тем же (надеюсь)…
Итак…
Во-первых…
>Set rs = CurrentDb.OpenRecordset("Select * from t where t.fio=""Иванов"";", , dbRunAsync)
>' На самом деле последний аргумент не нужен
и мотивация:
>CurrentDb.OpenRecordet без этого аргумента работает асинхронно, до тех пор, пока не начнешь обращаться еще к неподготовленным записям рекордсета. А-ля форма, которая показала первую запись, еще не дождавшись последней...
Здрасте на куй я ваша дядя (C) ЛП
По умолчанию все запросы и при запуске из любой библиотеки (дао/адо/акссес(ДуЦМД)) выполняются синхронно. "А-ля форма, которая показала первую запись, еще не дождавшись последней" реализована не через асинхронное выполнение. Т.е. открытие рекордсета из кода с умолчательными параметрами не есть открытие рекордсета формой с прописанными параметрами асинхронного режима.
Более того, часть запроса запущенного формой выполняется в синхронном режиме, а часть в асинхронном. Эдо дело рулится параметрами, грубо говоря, AsyncExecute, FetchCacheSize и AsyncFetch. "Грубо говоря" потому что в каждой библиотеке названия свои… AsyncExecute отвечает за то, что запрос должен выполняться асинхронно; AsyncFetch говорит что часть запроса должна быть выполнена синхронно, а оставшаяся часть – асинхронно; ну и FetchCacheSize характеризует какое количество записей должно быть возвращено запросом в синхронном режиме, при этом все остальные записи возвращаются уже в асинхронном.
Так вот формы при открытии указывают следующие параметры: AsyncExecute = True, FetchCacheSize = 500 и AsyncFetch = True. В результате мы видим, что в момент возникновения OnOpen формы (самое первое событие) рекордсет содержит 501 запись (количество возвращенных записей в синхронном режиме). Все остальные записи будут возвращаться в асинхронном, а значит в момент, когда более приоритетные потоки (в нашем случае поток, выполняющий VBA код) простаивают. Желаешь убедиться? Сделай так:
1) Создай ленточную форму на основе длинющей-длинющей таблички;
2) в заголовке формы создай текстовое (свободное) поле;
3) установи таймер в одну секунду
4) по таймеру пихай в текстовое поле количество записей в рекордсете, подключенном в форме;
5) убедись, что загрузка записей производится…

А теперь пункты 1 и 2 те же, а вот остальные следующие:
3) установи таймер в 1 мс;
4) в процедуре таймера запусти бесконечный цикл (Do … Loop без параметров) внутри которого читай количество записей в рекордсете и выводи в текст бокс.
Убедись, что загрузка записей НЕ производится…

И в том и в другом варианте на всякий случай делай репаинт...

На счет твоего теста… Вот не знаю как там DAO обходится с асинхронностью (но точно по умолчанию режим синхронный), но вот как ADO обходится – знаю, поэтому буду судить о твоем тесте по "правилам" ADO.

Выполнение "Последовательно" – ну здесь всё просто.
Выполнение "Параллельно" – всё не так! Даже если ЛП не прав на счет асинхронности только для ОдиБиСи и предположим, что запрос выполнялся всё ж таки асинхронно, то вот что произошло:

Т.е. переключений здесь – минимум! Это последовательное выполнение, а не параллельное. В контексте Access (даже не Виндоус, а именно Аксесс) асинхронное выполнение – это не параллельное выполнение, а выполнение "в промежутках". И пример с 11-ой секундой был направлен на "развеивание" мифа о ускорении программы при разделении выполняемого кода на два потока – однопроцессорная машина эти самые два потока выполнит не за 10 сек, а за 11, при этом 1 секунда уйдет на переключения между потоками.

Кстати, если будешь выполнять описанный мной тест с формами, то проделай следующее – открой сразу две копии одного и того же мдбэшки, расположи рядом (чтобы было видно и то и другое), запусти 1-й вариант теста и попереключайся между этими задачами. О результатах расскажешь :)

Ну как мог…

з.ы. щаз увидел продолжение дискуссии, но уже завтра... усе завтра... в смысле сегодня, но завтра :)

Поправочка...
Начиная с
"Здрасте на куй я ваша дядя (C) ЛП "

По умолчанию все запросы и при запуске из любой библиотеки (дао/адо/акссес(ДуЦМД)) выполняются синхронно. "А-ля форма, которая показала первую запись, еще не дождавшись последней" реализована не - (лишнее, надо выкинуть!) через асинхронное выполнение. Т.е. открытие рекордсета из кода с умолчательными параметрами не есть открытие рекордсета формой с прописанными параметрами асинхронного режима.

Конечный вариант правки:
Здрасте на куй я ваша дядя (C) ЛП
По умолчанию все запросы и при запуске из любой библиотеки (дао/адо/акссес(ДуЦМД)) выполняются синхронно. "А-ля форма, которая показала первую запись, еще не дождавшись последней" реализована через асинхронное выполнение . Т.е. открытие рекордсета из кода с умолчательными параметрами не есть открытие рекордсета формой с прописанными параметрами асинхронного режима.

Еще... На самом деле форма может возвращать в синхронном режиме либо все записи, либо 501, либо то количетсво записей, которое в данный момент может быть отображено на экране... Но это уже в следующий раз как-нибудь...

Еще "еще"... В твоем тесте в цикл надо вставить отображение количества загруженых записей (хотя бы так, как это сделал я - через отображение в текстбоксе) и... убедиться, что в таком цикле нифига записи не будут грузиться, а если и будут, то только за счет жалости виндоус - поток с запросом попадет в статус "голодающих" и винда будет ему иногда подкидывать процессор. Дело изменится, если ты в цикл вставишь DoEvents, сознательно отказваясь в потоке VBA кода от выделенного кванта времени в пользу других. вот тогда ты увидишь реальную загрузку данных в асинхронном режиме, реальное поочередное выполнение потоков в многозадачной системе и вот именно здесь ты и получишь результаты замера по времени с 11-ой секундой! :)

Всё! Спать!