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-ти мегов оперативки.... Ну это ты пользователю будет сугубо лично индифферентно.
А что база по размеру не расширяется постоянно?