FAQ по производительности доступа Тони Тоевса - лучшее место для начала, на мой взгляд.
Тем не менее, описанные вами проблемы звучат так, как будто они подразделяются на два класса:
A. медленно открывающиеся формы.
B. медленные формы исполнения.
Есть две распространенные причины A:
создание файла LDB / конфликт за него с существующими пользователями. Эта проблема обычно решается с помощью какой-либо формы решения из статьи о блокировке LDB Тони . Вы можете сказать, является ли это причиной проблемы, если открытие первой формы происходит медленно, а открытие последовательных форм не замедляется, если оставить исходную форму открытой. FWIW, я не использую этот метод, но использую постоянную переменную базы данных, которая выполняет то же самое (не самый последний раз, когда я разместил код на SO, но, возможно, тот, который имеет лучший контекст, здесь: Доступ MS: Существуют ли значительные издержки при использовании CurrentDB, в отличие от DBEngine (0) (0)? ).
устаревшие метаданные в связанных таблицах. Это может произойти, если, например, вы работаете во внешнем интерфейсе на тестовом сервере, переместите его в производственную среду и обновите строки подключения, чтобы они указывали на производственный сервер. Обновление строки подключения не обновляет все метаданные, хранящиеся в определениях связанных таблиц, и фактически невозможно полностью обновить их. Таким образом, вы должны удалить и воссоздать связанные таблицы в производственной среде. Признак этого состоит в том, что в тестовой среде формы открываются немедленно или через секунду или две, а в производственной среде для открытия требуется минута или больше. После открытия они вообще работают просто отлично. FWIW, я действительно не видел эту проблему, кроме как в первые дни Access 2000, когда это была серьезная и ужасная проблема, которая почти стоила мне работы (мой первый проект A2000).
Медленно работающие формы сложнее исправить, но причина обычно довольно проста: формы загружают слишком много данных одновременно. Формы с большим количеством подчиненных форм (обычно на элементе управления вкладками) и большим количеством больших полей со списком являются обычным виновником. Решение состоит в том, чтобы не загружать подчиненные формы / поля со списком, пока они фактически не отображаются. В элементе управления вкладками это означает загрузку подчиненной формы для каждой вкладки в событии OnChange элемента управления вкладками. Для комбинированных окон их следует загружать, когда они отображаются, или если в них слишком много записей (я бы сказал, более 1000), не загружайте источник строк до тех пор, пока пользователь не введет 1 или 2 символа ( используя событие OnChange поля со списком).
Проблема в том, что вы торгуете одним крупным замедлением (загружая все эти вещи при первом открытии формы) для ряда гораздо меньших замедлений (загружая каждую подчиненную форму / источник строк по мере необходимости). Это компромисс, и вы должны решить, где вы хотите, чтобы ваша боль.
Есть много других вещей, которые нужно сделать, и одна вещь, которую нужно изучить на раннем этапе при устранении проблем с производительностью, - это источник записей каждой основной формы. Левые объединения могут стать очень дорогими с точки зрения производительности, и это хорошая идея, чтобы исключить любые из них, которые не являются абсолютно необходимыми. Я только недавно значительно ускорил форму, у которой было левое соединение с родительской таблицей из дочерней таблицы. Ребенок не мог существовать без parentID в поле PK в дочерней таблице, поэтому оставленное соединение было совершенно ненужным. Удаление действительно ускорило навигацию от записи к записи.