ShamanusПеред запуском проги идет загрузка большого объема данных. Примерно 10 секунд.
DoEvents
или описывай подробно, что такое загрузка данных.

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

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

а вообще, загрузка такого объема данных в массив наводит на мысль об ошибках проектирования системы

ShamanusВарианта реализации я вижу 2.
Первый - sql запрос к источнику данных в момент заполнения поля. Время работы запроса 3-7 секунд.

Неверная индексация БД

ShamanusВторой - полная загрузка данных и поиск в массиве. Время работы 7-10 секунд. Время поиска записи в массиве менее 0,5 секунд.

И куча занятой памяти под массив.

Идиотское решение (пойдем в категоричности стопами Антонария)


Кроме того, проверку при таком объеме надо делать на на Change, а на окончание ввода: потерю фокуса, нажатие Enter, нажатие кнопки сохранить и т.п.

Shamanusнашел вот такое решение
сейчас попробую, вроде то, что нужно....
это и есть асинхронный запрос.

Но еще раз - не надо грузить в массив 300к записей! Для этого существует БД!!!!!

Shamanus Все таки не всегда быстрее запрашивать. Индексы нельзя построить если обращение идет к объединению таблиц. (не партициям, а именно множеству таблиц)
что именно и есть в моем случае
Это что еще за глупость?
Допускаю, что ты просто недостаточно внятно выразил мысль....

Shocker.ProShamanus Все таки не всегда быстрее запрашивать. Индексы нельзя построить если обращение идет к объединению таблиц. (не партициям, а именно множеству таблиц)
что именно и есть в моем случае
Это что еще за глупость?
Допускаю, что ты просто недостаточно внятно выразил мысль....
Кроме того, всегда существует возможность физической реализации плоской таблицы с нужными данными и ее индексирование

ShamanusБаза содержит union запрос из нескольких запросов к этим таблицам. Которые объединяют её в одну.
У меня обращение из программы идет к этому запросу, с целью получения общей картины.
Ну это не отменяет использования индексов.... хотя.... union в аксессе дурной и тормознутый, это я проходил. Может быть можно использовать обращения отдельно к индексам каждой таблицы?
Shamanus
Почему таблица фрагментирована?
- местоположение программы, структурное подразделение компании не имеющее доступа в центральную БД, им приходится скидывать БД. Т.к. таблица весит 15 метров, и 7 в архиве, из-за каждого update в одну строку, высылать всю таблицу с нуля некошер. Высылаем обновленный фрагмент.
Ну, конечно, по-хорошему, это делается на MSSQL с дистрибуцией транзакций, но причин, по которым вы не используете MSSQL может быть конечно же много.
Shamanus- сама база Access тоже периодически обновляется, поэтому сливать фрагменты при каждом обновлении в кучу и строить индексы тоже неверно. Автоматизировать этот процесс нельзя.
+ есть лимит на размер почтового вложения 2 мб. - нужно чтобы фрагмент и база вкладывались в этот лимит.
Я намекал на то, что можно теоретически, вместо памяти сливать эти данные в локальный mdb-файл. Тогда во-первых эту операцию можно будет проделывать не при каждом запуске программы, а только по необходимости, ну и, соответственно, нет проблем с индексированием.
Лично я довольно косо смотрю на процесс, который отжирает от 15-ти мегов оперативки....

ShamanusДумал построить индексы на union запрос нельзя в принципе.
Индексы строятся на таблицы, а не на запросы (материализованные представления в MSSQL опустим). Запросы используют эти индексы. Другой вопрос, что аксесс плохо (по крайней мере лет 5 назад, щас не знаю) работал с UNION-ами в плане скорости.

другой вопрос, что ты ищешь Like-ом. Тут индексы - да, не помогут.

Shamanusя вот чето не пойму, как это при необходимости? Все равно нужно будет при запуске проверять изменилось ли чего. А count по количеству записей будет отрабатывать также долго.
или хранить дату/время создания фрагментов? А откуда прога знает сколько фрагментов?
Почему также долго? Если Like не использует индексы, то Count-то - вполне.

Насчет фрагментов - не знаю, как у тебя устроены изменения этой структуры. Твой UNION-запрос как-то ведь об этом узнает...
ShamanusShocker.ProЛично я довольно косо смотрю на процесс, который отжирает от 15-ти мегов оперативки.... Ну это ты пользователю будет сугубо лично индифферентно.
А что база по размеру не расширяется постоянно?

Можно еще AutoRefresh форме поставить

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

aduka05admкороче че то я не понял зачем этот DoEvents
уже пишу свои попытки объяснить....

Адука запутался. Попробую я его еще больше запутать или распутать.

Давай только откажемся от термина "фоном" - это понятие относительное и диалектическое.

Итак. Синхронные действия (обычные для VB). Код выполняется последовательно, друг за другом, если выполняется долгая операция, весь остальной код тупо ждет (даже если это запрос к серверу БД, выполнение которого зависит от сервера, а не от твоей программы). Закончилась одна команда - началась следующая.
События при этом встают в очередь. Любые, кнопки, клавиши, клики, таймер. Если у тебя сработал таймер, событие от него не будет немедленно выполнено, а встанет в очередь и дождется завершения твоего текущего кода.
То есть заканчивается выполнение текущего кода (а это тоже в 99,9 случаев обработка события), начинает выполняться следующие, остальные ждут.
Вот. Это обычный синхронный режим.

А есть такая интересная штука - DoEvents. Она вовсе не вводит асинхронность и многопоточность. Она просто берет и твой текущий код переносит в конец очереди событий. То есть ты делаешь DoEvents, твоя текущая процедура останавливается, начинают выполняться все события, которые ждали своей очереди. Потом управление вернется к твоей процедуре. Если событий в очереди не было - ничего как бы не произойдет.

пока вникай, пишу далее....

С помощью DoEvents можно сымитировать многопоточность.
К примеру, у тебя прыгает по экрану чертик. Тупо в цикле:
В этом случае код зациклится, будет рисовать чертика, но с точки зрения пользователя не будет реагировать ни на какие раздражители, включая закрытие формы. Почему? Потому что события от пользователя ждут, когда закончится твой код, а он не закончится никогда.
Как сделать, чтобы реагировало.
Пока событий нет, цикл крутится, как и крутился. Пользователь нажал на кнопку "отмена" - после очередной прорисовки чертика управление будет передано кнопке "Отмена". Кнопка просто установит флажок (переменную), что она была нажата. Цикл увидит, что кнопка была нажата и завершится.
Кроме того, чертик будет себе прыгать, а пользователь может переключаться на другие формы того же приложения и делать там все, что хочет. Можно даже запустить несколько таких циклов, они все друг другу будут передавить управление и все чертики будут прыгать.

теперь про асинхронность....

Асинхронное выполнение запроса напоминает работу с таймером. Ты дал команду серверу выполнить запрос (завел таймер), сервер сказал "ок" и пошел думать. Твоя же программа получает управление взад и можешь дальше делать, что хочешь. Обрабатывать нажатия кнопок и т.п. Или рисовать на экране прыгающего чертика.
Когда сервер закончит возиться с твоим запросом (когда у таймера настанет время), он выдаст событие - завершил. Вот для этого и важен в рисовании чертика DoEvents - иначе ты просто не поймаешь событие от ADO, когда твой запрос будет готов.

Но лучше пойти дальше - не рисовать чертика с использование DoEvents, а рисовать его по таймеру. то есть заводишь таймер на 300 мс, и по каждому событию рисуешь новое положение чертика. Тогда у тебя программа вообще не занята ерундой. Она просто сидит в ожидании событий. Пришло событие от таймера - перерисовал чертика. Пришло событие от ADO - начинаем обрабатывать результаты запроса - вот и вся асинхронность.

ЗЫ:
Кстати, я не использую тот метод, пример которого ты нарыл. После того, как я получил от сервера событие, что данные готовы, я начинаю заполнять этими данными сетку. Но в цикле после каждой строки делаю DoEvents. В результате, я совершенно не мешаю пользователю работать с другими формами или контролами на этой же форме, включая возможность вообще отменить заполнение сетки.

aduka05adm,

И немножко про многопоточность (мультизадачность). С помощью DoEvents ты создаешь псевдомультизадачность (но выглядит она как настоящая). С помощью асинхронного выполнения запроса - уже реальная мультизадачность. Кроме того, не очень сложно запустить в VB второй поток, и параллельно выполнять два своих кода.

Самый большой гемор - это синхронизация и изоляция потоков. Это жуткая головная боль. Хорошо сделанных многопоточных программ очень мало (могу привести в пример The Bat! - там реально отрисовка письма, проверка почты, проверка антиспамом, пересчет и индексирование папок идет независимо и при этом не глючит - это дает пользователю нормально работать, а не ждать, пока закончится какая-то операция).

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

aduka05adm
только вот еще вопрос
здесь как это все будет работать
здесь все лэйблы будут поочереди срабатывать, пока запросы очереди ждут?
Ща почитал повнимательней, о чем вы переписывались с Игорем....
Там DoEvents не служит никакой асинхронности и лучше его, наверное, не использовать...
просто после каждого
Form1.Label1.Caption =
поставить
Form1.Label1.Refresh или Form1.Refresh
Просто, как правило, отрисовка экрана не происходит, пока не закончатся все события в очереди или кто-нить не даст DoEvents или Refresh. Но так как имеет другие побочные эффекты, можно обойтись Refresh для ясности.

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

aduka05admShocker.Pro,
Shocker.ProВ результате, я совершенно не мешаю пользователю работать с другими формами или контролами на этой же форме, включая возможность вообще отменить заполнение сетки.
то есть у вас здесь также как в цикле с чертиком , если наступает событие то передается управление пользователю?
Не пользователю - а событию, которое мог вызвать пользователь (нажать кнопку, закрыть форму...)

aduka05admесли стоит DoEvents перед строкой кода то, она помещается в конец очереди
как например
то есть мы можем далее работать с формой


Нет, недоразобрался ты....
Не строка, которая следует за DoEvents помещается в конец очереди, а вся твоя процедура. То есть последовательность выполнения строк в твоей процедуре никак измениться не может.
Будут выполняться другие события, но не код твоей процедуры. До тех пор, пока другие события не закончатся.

aduka05adm
так вот может быть ситуация что какой сбой и в первую таблицу данные занеслись
а во вторую нет (как вы сами такое реализуете )?
то есть хочется все или ничего (транзакция называется по мойму)
но как это на VB реализуется
Напомни, какой СУБД ты пользуешься?