@GenriF

Для доступа к базе данных использую компоненты TADOConnection и TADOTable. База данных примерно на 7000 записей на примерно 20 полей, сформирована в Access.

Типичное использование базы данных - фильтрация по одному полю и заполнение ComboBox значениями другого поля в пределах отфильтрованного набора данных. При фильтрации отбирается как правило не более 200 записей.

Именно на процедуре активации фильтра и заполнения ComboBox и происходит существенное подтормаживание, на секунд 40 программа подвисает. Причем чаще всего это происходит при запуске приложения, данная функция у меня включена в событии главной формы OnCreate. Периодичность подвисания в среднем 1 раз в 15 запусков приложения. Хотя иногда бывает через раз, а иногда и через 50 запусков.

Во время работы приложения тоже применяется такая функция (фильтрация и заполнение ComboBox), но зависания случаются заметно реже, по ощущениям раз в 5.

Можно ли как-то ускорить работу с базой данных через какие-то специфические настройки компонентов доступа к данным? Или каким-то другим способом. Недавно расширил эту базу данных на тысячу записей примерно и подвисания стали случаться чаще и это стало напрягать.

0

@didgik

Сделай вывод в лог времени после каждой операции и смотри где касяк.

0

@D1973

Вот это - основная причина тормозов.
При использовании компонентов T...Table программа при первом обращении грузит в память ВЕСЬ набор данных, нужен он в текущий момент или не нужен - ей пофигу. Сами понимаете, что чем больше этот набор данных - тем больше времени занимает его загрузка в память. А тем паче, если этих наборов несколько.
Причем база данных может располагаться как на другом краю света, так и лежать рядом с ехе-файлом приложения - разницы абсолютно никакой, разве что при удаленном расположении базы накладываются ограничения, связанные с пропускной способностью канала связи...
Потом работа происходит нормально и быстро, но все это происходит с локальной копией НД в памяти. И рано или поздно наступает момент, когда компонент T...Table решает синхронизировать данные локального НД с данными в самой БД. А что происходит в этот момент? Правильно, все 100500 записей передаются обратно из памяти в БД, а потом, в случае многопользовательской базы, снова ВСЕ данные из БД тянутся на клиента. И происходит это с периодичностью... А вот пес его знает, с какой периодичностью, это, как и порядок сортировки, спрятано "под капотом" компонента и повлиять на этот процесс Вы не можете.
Поверьте, когда база вырастет на порядок - на порядок же вырастет и время ожидания. И, итогом, когда-нибудь наступит тот прекрасный момент, когда программа у Вас будет вылетать при старте с сообщением о нехватке памяти...
Вот! О чем я и говорю. Зачем Вы тянете себе все свои 7000+ записей, если Вам, по факту, требуется всего 200?

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

Можно.
1. Использовать нормальные инструменты для работы с БД - SQL-запросы. И, соответственно, компоненты TADOQuery
2. Пересмотреть интерфейс программы без отображения бесполезной информации.

3

@TrollHammer

0

@GenriF

Нет, такой таблицы нету. База данных используется только для выборки определенных записей, которые нужно отобразить в данный момент времени. Причем под "отобразить" - я подразумеваю всего лишь заполнение ComboBox данными одного из полей отфильтрованного набора. Ну и кроме того, функционал программы использует значение еще примерно 5-ти полей, которые пользователю вообще не выводятся. А около 15-ти полей не нужны вообще - ни для отображения, ни для внутренней работы программы. То есть БД обладает избыточным набором данных, который не нужен конкретно для этой программы (но нужен для других).

Надо попробовать через ADOQuery все сделать.

0

@GenriF

Поменял Table на Query, притормаживания пропали. Спасибо!

0

@D1973

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

0

@GenriF

Да, по запросу всегда выбирается небольшое количество записей.

Вообще изначально применял Table, почитав Архангельского (см. вложение). У меня как раз локальная БД, всего один пользователь, это вообще приложение для моих собственных нужд по роду основной профессии. По сути просто некоторые справочные данные.

Миниатюры

 

0