Оптимизация приложений в Access

Иногда при разработке приложений возникает ситуация, когда еще недавно работающая программа вдруг начинает «тормозить», запросы, ранее выполнявшиеся что называется «в полсекунды» начинают зависать и т. д. Попробуем разобраться, что может быть причиной этому и составить общие рекомендации по поводу оптимизации приложений. Как известно, в Ассеss есть мастер, позволяющий провести беглый анализ приложения. Жмем Сервис - Анализ - Быстродействие - Все типы объектов - Выделить все - ОК. Итак, что же обычно мы видим?

Приложение не сохранено в полностью откомпилированном виде.

Это означает, что нужно преобразовать базу из формата .mdb в формат .mde. Делать это нужно закрыв приложение и запустив Access. Далее находим Сервис - Служебные программы - Создать mde файл. Причем, если приложение создавалось в другой версии Access, ее сначала следует преобразовать в текущую: Сервис - Служебные программы - Преобразовать базу данных, а уже потом делать из нее .mde. В результате получится преобразованная копия базы (.mde).
 Начиная с версии Access 2000 поддерживается совместимость версий «снизу вверх». Это означает, что .mde файл сделанный в Access 2000 будет работать в более поздних версиях, а вот наоборот - не будет. Дело в том, что от версии к версии меняется формат .mde файла, и то, что понятно для Access 2002 - китайская грамота для Access 2000.
Преобразованная таким образом база будет работать быстрее, потому, что скомпилируются все модули приложения. Но в результате Вы уже не сможете редактировать формы и отчеты в режиме конструктора. Преобразовать .mde в .mdb обратно стандартными средствами Access так же будет невозможно. Об этом следует помнить и всегда сохранять исходную (.mdb) версию базы. Стандартными нельзя, но… Как известно, нет такого замка, которого невозможно открыть. Теоретически (да и практически) можно декомпилировать базу (и не такие программы «ломали»), но это уже относится к области «хакеров», и по понятным причинам в данной статье освещаться не будет. Остановимся лишь на одном интересном для начинающих разработчиков Access вопросе.
Часто программисты, ранее разрабатывавшие приложения в других средах (Си, Delphi, FoxPro и др.) спрашивают: «Как сделать в Access .exe? (исполняемый файл, способный работать сам по себе, без Access)». Ответ всегда один: никак.  И причин тому несколько:

дело в том, что изначально язык VBA разрабатывался как вспомогательное средство создания офисных документов, его определение в переводе так и звучит: «Визуальный язык программирования для приложений (офисных)», и само собой подразумевалось, что созданные с его помощью приложения будут работать только под управлением родительского приложения, в данном случае Access. Поэтому при компиляции в Access создается не машинный (двоичный) код, а так называемый p-код. Р-код близок к машинному, но программа в Р-коде не может быть непосредственно выполнена процессором. Преобразование (трансляция) в двоичный код происходит во время выполнения программы. Это сделано для отладки приложений. Без p-кода невозможно было бы прерывать выполнение приложений, редактировать тексты программ и снова продолжать выполнение. Кстати, аналогично ведь происходит и в других средствах разработки. Везде присутствует «промежуточная» трансляция.

хотя Microsoft постоянно совершенствует VBA, но «отдавать» его как средство для создания независимых коммерческих приложений не собирается. Очевидно, что в этом случае компания может потерять значительную часть прибыли от реализации новых версий Office, ведь для того, чтобы к примеру запустить приложение Access, созданное в более новой версии Access (с новыми возможностями), необходимо установить (купить) эту новую версию. Вообще, эта тема - коммерческое распространение приложений Access заслуживает отдельной статьи, и я постараюсь в одной из следующих статей подробно остановиться на этом. Пока скажу лишь, что проблема эта вполне решаема и многие успешно реализуют свои программы.

Про формат mde следует сказать особо. Очень часто начинающие разработчики создают базу данных, где данные (таблицы) и интерейс (формы, отчеты и т .д.) хранятся в одном файле. Хотя во многих руководствах по Access рекомендуется разделять базу на две части: файл с данными и клиентскую часть, причем последнюю жедательно преобразовать в mde. Почему же такая схема считается оптимальной?

Скорость

Файл mde является "родным" для Access, т.е. структура его близка к машинно-двоичному виду, практически это тоже самое как файл exe для Windows. Следовательно, если Вы выделите из базы данных таблицы (кстати по объему информации они всегда стоят на первом месте) и скомпилируете все остальное в mde файл, Вы получите программу с минимальным размером. Отсюда следует, что пользователи будут быстрее загружать программу и работать с ней будет надежнее и удобнее. Следует отметить такой момен: не тратьте много усилий на конвертирование mde файлов к другим версиям Access и не пытайтесь их открывать из других версий Access - это не получится. Файлы mde не имеют исходных текстов программ на Бэйсике, следовательно для компилятора Access - это китайская грамота, так же как для большинства из нас язык племени Юмба-Намба из Северной Африки. Как уже говорилось выше, для того, чтобы mde файл открывался в другой версии Access, он должен быть создан в более ранней версии (это справедливо для Access начиная с версии 2000).

Защита

Если Вы разрабатываете программу уже несколько лет и потратили много сил и энергии, то нет смысла ее распространять в открытом виде. Через 2-3 недели, изменив ваши авторские права на свои, уже кто-то начнет ее продавать как собственную разработку.

Надежность

Ядро Access легче обрабатывает базу данных в которой хранятся одни таблицы. Следовательно, если в вашей mde-программе есть скрытые ошибки в расчетах, то может произойти разрушение mde-файла, но в случае раздельного хранения данных Ваши данные в таблицах останутся.

Обслуживание

При работе в сети базу данных mdb размещают на сервере, а mde-программы на компьютерах пользователя. Если Вам надо поменять старую версию программы на новую, то не зачем останавливать всю работу предприятия в случае с одним mdb файлом. Вы просто отлаживаете mde-программу на своем компьютере, добавляете поля, таблицы в базу данных mdb на сервере, а потом заменяете по сети mde-файлы пользователей. Все это занимает несколько минут, и практически различные отделы, например, Бухгалтерия, Сбыт, ОТиЗ работают без остановки.

Совместимость

Если у Вас один файл mdb обеспечить совместимость разных версий Access практически не возможно, т.е. трудно будет работать с файлом mdb из Access версий 2, 97 и 2000. Если же mdb-таблицы хранятся на сервере, Вы можете подключиться к ним через внутренние или внешние драйверы ODBC из любой версии Access.

Мобильность

Если Вы работаете с программой складского учета, то Вам требуется описать примерно 40-50 разных таблиц для склада, администрирования или настройки. Но этого явно недостаточно, т.к. по складу должны проходить и таблицы, связанные с кассой, с банком и себестоимостью (~60 штук). Если все это записать в один файл, то не только бухгалтера, но и Вы начнете путаться в них. Поэтому и надо разделять базу данных на несколько частей.

Администрирование

Работая с "серьезной" базой данных надо заботиться о ее сохранении и развитии. Для этого существуют различные команды: архивирование и восстановление, копирование и удаление, репликация, т.е. добавление новых полей и таблиц. Все эти действия легче всего осуществить, если в Вашей базе данных будут одни таблицы. Зайдите на мой сайт и посмотрите введение к базе данных "Склад и Реализация", там есть что почитать.

Таблица … : свяжите с другими таблицами базы данных.

Как следует из ответа мастера, в базе есть не связанная с другими таблица. В некоторых случаях это оправдано - речь идет о так называемых «служебных» таблицах, в которых заносятся какие либо параметры приложения. В этом случае ответ мастера можно проигнорировать. А вот если речь идет о справочной таблице, откуда подставляются значения (ключи) в основную таблицу, то к мастеру стоит прислушаться. Дело в том, что Access относится к самому распространенному сейчас классу реляционных СУБД, основным признаком которого является то, что данные распределены в базе, словно одежда в платяном шкафу: носки в ящике для носков, штаны в ящике штанов и т. д. Помимо этого они еще и связаны между собой логическими связями. Например: Комплект верхней одежды - это штаны + рубашка + носки. Потянув за такую «нитку» машина может вытащить весь комплект и определить его состав, а это значит, что если вы зададите ей искать головной убор (шапку) - в раздел для верхней одежды она уже не полезет, стало быть, шапка найдется быстрее. Вот это мастер и пытается нам втолковать. То есть такая «правильная» база, это как хороший шкаф у аккуратного хозяина, в котором есть отделы, в отделах секции, в секциях ячейки. В свою очередь «плохая» база - это сундук, где все свалено в одну кучу - попробуй, найди там чего. Вообще, лично я, когда хочу определить уровень разработчика Access, первым делом смотрю, как связаны у него таблицы, как распределены данные. Причем иногда оказывается, что вообще никак. Дескать, пусть сам Access разбирается, что и с чем там связано.
Установка связей между таблицами делается в специальной вкладке Схема данных. Жмем сервис - схема данных или просто правой кнопкой в окне проекта и в контекстном меню выбираем схема данных. В открывшемся диалоговом окне снова жмем правой кнопкой и выбираем Добавить таблицу. В появившемся диалоговом окне раскрываем вкладку таблицы и выбираем нужные: щелкаем дважды по названиям и таблицы появляются в окне конструктора. Закрываем окно со списком таблиц.
Для установки связи между таблицами нужно выбрать в одной из таблиц (главной) таблице поле для связи, нажать левую кнопку мыши и перетащить поле во вторую таблицу. Отпустить левую кнопку мыши над тем полем подчиненной таблицы, с которым устанавливается связь. После этого появится диалоговое окно Изменение связей. Здесь можно поставить автоматическую проверку ссылочной целостности - флажок обеспечение целостности данных, и если требуется, каскадное обновление/удаление связанных полей. Я практически всегда включаю флажок обеспечение целостности данных, потому, что если этого не сделать, то в скором времени Ваша база забьется «мусором» - появятся ни с чем не связанные записи.

Таблица … : добавьте индекс для поля…

Индекс - это упорядоченный список значений и ссылок на те записи, в которых хранятся эти значения. Чтобы найти нужные записи, СУБД сначала ищет требуемое значение в индексе, а затем по ссылкам быстро отбирает соответствующие записи.
В каждой таблице должен быть так называемый ключ - идентификатор записи. Исключение составляют лишь специальные служебные таблицы, обычно с параметрами приложения, в которых, как правило, обычно не много записей. Чаще всего ключами делают поля типа «счетчик» - числовое поле с уникальными значениями. Но мастер просит проиндексировать еще одно поле в таблице, хотя в нем уже есть ключ-счетчик. Дело в том, что видимо в данном случае в каких либо запросах часто используется это поле, и по нему вытягиваются другие записи.  Если поле проиндексировать, то поиск (выполнение запроса) пойдет быстрее.
Однако индексирование может привести и к обратному эффекту. Дело в том, что при добавлении и удалении записей или при обновлении значений в индексном поле требуется обновлять индекс, что при большом количестве индексов в таблице может замедлять работу. Поэтому индексы обычно рекомендуется создавать только для тех полей таблицы, по которым наиболее часто выполняется поиск записей. Индексировать можно любые поля, кроме МЕМО-полей, полей типа Гиперссылка и объектов OLE.
Итак, открываем таблицу в режиме Конструктора, выбираем поле, для которого требуется создать индекс, далее вкладка Общие и выбираем для свойства Индексированное поле значение Да (Допускаются совпадения) или Нет (Совпадение не допускаются).
Индекс может быть так же и составным. Обычно такую индексацию применяют, когда нужно задать уникальные значения для группы полей. Например, в одном поле номер договора, в другом идентификатор. Нужно, что в таблице разрешалось сохранение данных типа 12П, 12Р, 12Н, а вот два раза 12П не разрешалось - сразу должно появиться сообщение о повторяющихся записях. Делается это просто: снова открываем таблицу в режиме Конструктора, на панели инструментов Конструктор таблиц жмем кнопку Индексы. В первой пустой строке поля Индекс вводим имя индекса, затем в поле Имя поля жмем на стрелку и выбираем первое поле, для которого необходимо создать индекс. В следующей строке поля Имя поля указываем второе индексируемое поле, причем для данной строки поле Индекс должно оставаться пустым. Далее повторяем это для всех полей, которые необходимо включить в индекс (разрешается включать в индекс до 10 полей).

Форма (модуль) … : добавьте инструкцию Option Explicit.

Во многих языках программирования переменные должны быть объявлены обязательно, и эти объявления используются компилятором, чтобы зарезервировать память для переменных. В то же время в VBA объявление переменных не является обязательным, и допускается использование неописанных переменных.
Когда-то среди программистов, использующих разные языки программирования, велись споры по поводу необходимости обязательного описания всех переменных. Действительно, кому охота занудно прописывать каждую переменную Dim i As Integer, j As Integer и т. д. Однако другой стороны, один из самых опасных источников труднообнаруживаемых ошибок в языках программирования, допускающих применение неописанных переменных, это опечатки в написании имен переменных. Такие опечатки истолковываются транслятором как появление еще одной, новой переменной, отличной от ранее использовавшейся, и не воспринимаются как ошибки. Порой для обнаружения такой опечатки требуется время, во много раз превосходящее то, которое потребовалось бы на явное описание всех используемых в программе переменных.
В VBA решено было так - предоставить разрешение этой дилеммы самому программисту. В этом языке имеется оператор Option Explicit. Если Вы начнете свой модуль с этого оператора (он должен быть расположен в самом начале модуля, до того, как начнется первая процедура этого модуля), то VBA будет требовать обязательного объявления переменных в этом модуле и генерировать сообщения об ошибке всякий раз, как встретит необъявленную переменную. Кроме того, чтобы это требование стало обязательным для всех модулей без исключения, можно установить параметр Require Variable Declaration (Явное описание переменных) на вкладке Editor (Редактор) диалогового окна Options (Параметры) редактора VBA.
Если же не использовать Option Explicit и переменные не объявлять, то переменной по умолчанию присвоится тип Variant. Вот на это и ругается мастер - на переменную общего типа.  Дело в том, что такие переменные занимают больше места в памяти по сравнению с данными других типов, а главное, они не могут быть обработаны немедленно. Когда компилятор обнаруживает вариантную переменную, то сначала должен выяснить ее настоящий тип, преобразовать в него данные, а уж потом делать с ними вычисления. На все это требуются время, и если в простых приложениях, где нет сложных вычислений,  можно применить переменные типа Variant, то в сложных, особенно где происходит много вычислений с двойной точностью, разница по скорости вычислений может отличаться в разы. Вообще, у профессиональных программистов VBA считается хорошим тоном прописывать в заголовке Option Explicit - тем самым вы избежите не только вышесказанные проблемы, но и многие другие, касающиеся не только производительности.

Форма…: используйте меньшее число элементов.

Это пожалуй, самая часто встречающаяся рекомендация мастера. Действительно, многие начинающие разработчики стараются «навешивать» на одну форму множество элементов: полей, полей со списками, подчиненных форм, вкладок на которых опять поля, подчиненные формы и т. д. Все это делается с целью сделать приложение более «наглядным», чтоб «все сразу было видно». Чем это чревато? Потерей скорости загрузки такой формы.
Дело в том, что обычно каждый элемент (контрол) имеет связанный с ним источник данных, который нужно «подцепить» при открытии. Не зря ведь существует столько событий формы, связанной с ее запуском: открытие, загрузка, включение, получение фокуса - как раз для того, чтобы управлять процессом «подцепления» данных, когда нет возможности использовать меньше элементов. Рассмотрим обычные ошибки начинающих разработчиков и способы из устранения.

1.     Число записей в форме

Бывает так, что прежде нормально грузившаяся форма, вдруг начинает «тормозить». Одной из причин может быть то, что источник данных такой формы - вся таблица, которая, как известно, заполняется. Все нормально, пока данных там порядка нескольких тысяч, но стоит поработать с базой несколько лет - и количество записей (особенно в бухгалтерских программах) может перевалить за несколько сотен тысяч. И при работе такая форма заметно потяжелеет, особенно, если она сделана как подчиненная на основной. Как выход - использовать в качестве источника данных формы запрос, где количество записей можно ограничить, например, периодом дат (текущий год, месяц).

2.     Подчиненные формы.

Старайтесь не использовать больше одной - двух подчиненных форм на основной. Помните, что при открытии основной формы последовательно происходит загрузка в саму форму и подчиненные, что требует времени. Особенно это касается форм с вкладками, на которых расположены подчиненные. Если отказаться от такого дизайна не получается, тогда применяйте динамическую привязку данных к подчиненным формам при переходе по вкладкам, используя свойство формы RecordSource:

Еще один признак начинающего разработчика - наличие на форме множества скрытых полей и подчиненных форм, которые используются либо для вычислений, либо в случае с формами - как своеобразный фильтр для получения значения поля из таблицы по заданному параметру (значению в другом поле). Такой способ действительно прост: источником данных такой формы делается запрос, в котором есть ссылка на поле главной формы Forms!frmGlawn!Поле1. В нужный момент делается обновление формы (Requery) и считывается значение из подчиненной формы. Но если таких форм прицеплено несколько, и каждый раз их обновлять - это может заметно сказаться на скорости работы приложения. Лучше вместо этого воспользоваться стандартной функцией:

3.     Поля со списками.

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

     Мы рассмотрели только самые простые рекомендации, которые смог определить мастер. Можно еще добавить:

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

если убрать галочку Сервис - Параметры - Вкладка общие - Отслеживать автозамену имен, то приложение будет работать быстрее

Оптимизация аппаратных средств.

Каждый модуль Access обладает множеством возможностей для настройки приложения, но нельзя рассчитывать на какой-либо успех в работе, если компьютер, на котором выполняется приложение, является устаревшим или имеет недостаточно оперативной памяти. Microsoft в аннотации к Access указывает минимальные системные требования для компьютера. Но практика показывает, что подобных ресурсов хватает лишь на то, чтобы программа что называется «задышала», а вот чтобы нормально работать, требования надо серьезно увеличивать.

Если выбирать между модернизацией процессора и установкой ОЗУ большего объема, следует выб­рать ОЗУ. Как известно, памяти много не бывает, а Access, как и любая другая серьезная база данных, для своей нормальной работы требует значительного объема памяти.

Необходимо регулярно очищать корзину и удалять временные файлы (особенно файлы Internet и электронной почты!). Базы данных требует значительного объема дискового пространства, а эти файлы могут поглотить массу места еще до того, как пользователь успеет это осознать.

Не лишним будет регулярное сжатие базы данных. Начиная с версии Access 2000 это можно настроить автоматически. Сервис - Параметры - Вкладка общие - Сжимать при закрытии. Дело в том, что в Access есть своя «корзина», и при удалении записи не удаляются, а помечаются как удаленные (знаком *), то есть «становятся в очередь на удаление». Так же в Access есть скрытые системные таблицы, в которых хранятся параметры форм. Форму удалили, а параметры остались. Потом они конечно удалятся, но это потом. А пока мы имеем «мусор» - ненужные данные. По этой причине часто начинающие разработчики удивляются, когда после удаления (стирания) записей из базы ее размер почему то не очень изменяется. Особенно это касается полей типа OLE, где хранятся рисунки формата .bmp. Забили базу рисунками, она «раздулась» до нескольких десятков мБ, удалили рисунки - а размер остался. Выход - сжатие базы (дефрагментация). Так же замечено, что при регулярном сжатии база становиться более устойчивой - реже «слетает».

Рекомендуется отключить Journal (Журнал) в Outlook. Журнал Outlook генерирует запись при каждом запуске и выходе из приложения. Этот журнал может стать очень большим и поглощать дисковое пространство и процессорное время, необходимые приложению.

Необходимо использовать освободившуюся оперативную память. Приложения очень хорошо погло­щают оперативную память, но неохотно ее освобождают. Не стоит запускать несколько приложений одновременно. Вообще, желательно, чтобы машина, на которой установлена база, была ориентирована в первую очередь на работу с базой - не стоит ставить на нее ненужные программы. Особенно это касается машин, которые используются в качестве «серверов» при файл-серверном построении сетевой базы. А то иной раз частенько на таком «сервере» работают как на клиенте, да еще запускают какое-нибудь «навороченное» приложение, да и не одно, а потом удивляются, почему вдруг сетевая база стала «тормозить».

У многих разработчиков компьютеры намного более быстродействующие, чем у пользователей. Это следует учитывать при разработке приложения, и протестировать его на более «слабой» машине. Так же, если Вы разрабатываете приложение, не зная точно, какой Office будет у пользователя, будет не лишним протестировать его на всех версиях, на которых оно предположительно может быть установлено. Лучше всего установить на машине несколько операционных систем и на каждой соответствующую версию Office - это даст наиболее «чистый» результат тестирования. Так же если Вы переустанавливаете Office, то следует помнить, что многие «серьезные приложения» приложения «мусорят», если не сказать больше, в системный реестр. И чем «серьезнее» приложение, тем больше. Поэтому после удаления программы, не лишним будет прочистить реестр, например, при помощи RegCleaner, а то и вручную через RegEdit.exe, и «добить» что осталось через Norton Utilities Integrator.

Оценка производительности

Естественным является желание посмотреть, что же дала оптимизация, насколько быстрее стало работать приложение. API Windows предлагает таймер, который отслеживает время в миллисекундах. ФункцияtimeGetTime() измеряет промежуток времени с момента запуска Windows. Поскольку она использует другой аппаратный счетчик, то возвращает время с точностью до миллисекунды. Используя timeGetTime(), можно вставить строку кода до и после выполнения любой критической опе­рации и получить очень точное измерение времени, которое понадобилось для завершения действия. Для использования вызова API необходимы две вещи: объявление функции и глобальная переменная для хранения времени запуска таймера. В разделе объявлений модуля необходимо ввести следующие три строки:

Затем можно создать подпрограмму для запуска часов и функцию остановки часов.

А вот пример использования этих функций:

Для достижения наибольшей точности измерения необходимо разместить вызов процедур a2kuStartClock и a2kuEndClock как можно ближе к местонахождению рассматриваемой процедуры.

Хотя определение времени играет не последнюю роль, но только на основе этой информации невоз­можно судить о производительности приложения во время разработки. Как уже говорилось выше, обычно у разработчика более высокоскоростной компьютер, стало быть тестирование не совсем «чистое», ведь таймер не может сообщить, как будет выполняться приложение на другом компьютере с меньшим объемом памяти или более низкоскоростным диском. Для более точного наблюдения за приложением можно воспользо­ваться другой недокументированной функцией - ISAMStats. Функция ISAMStats не документирована и не поддерживается, поэтому информацию, которую она сообщает, можно использовать лишь в качестве общих указаний. При запуске функция производит измерение шести важных оказывающих влияние на про­изводительность операций. Она подсчитывает все обращения чтения и записи на диск, обращения чтения в кэше, опережающего чтения, размещения блокировок и освобождения блокировок. Данную функцию можно использовать в Access 2000 и даже в более ранних версиях Access. Синтаксис функции очень простой:

     Существует шесть возможных значений для аргумента опция:

Необязательный параметр переустановки позволяет переустановить отдельные счетчики на нулевое значение. Чтобы воспользоваться данной функцией для оценки производительности, необходимо либо вычесть одни показания из предыдущих, либо переустановить счетчик на нулевое значение и затем вы-поднять оценку. Рассмотрим один из способов использования функции ISAMStats для оценки производительности.

PrintStats может дать некоторое представление о том, почему одна методика работает быстрее, чем другая. Кроме того, эта информация может помочь сделать выбор между двумя подходами, выполнение которых занимает одинаковый промежуток времени. Взглянув на полученные данные, можно определить, как разная аппаратная конфигурация или больший набор данных может повлиять на производительность того или иного подхода. Рассмотренные функции полезны только при сравнении одной методики с другой. Бо­лее того, надежные результаты можно получить лишь в том случае, если усреднить данные многих тестов, проведенных при разных условиях. Данные две функции можно с легкостью объединить в одну для проведения подобных повторяющихся тестов.

Создание связей между таблицами в конструкторе (схема данных).

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

Повышение скорости выполнения запросов.

     Вот основные рекомендации:

Рекомендуется создавать индексы для всех полей, которые будут использованы для определения критерия отбора.

В результирующем наборе не следует отображатькакие-либо лишние столбцы. Обработка и отобра­жение каждого столбца занимает дополнительное время.

Рекомендуется воздерживаться от употребления сложных выражений в запросах.

Следует избегать функцииIIF() (немедленное IF).IIF() оценивает и истинное, и ложное значения перед тем, как выдать результат. Если выполнять данную операцию для каждой записи, это может сильно повлиять на производительность.

По возможности следует пользоваться оператором Between для уменьшения количества строк в ре­зультирующем наборе вместо операторов "больше чем" и "меньше чем".

Рекомендуется по возможности поэкспериментировать с подчиненными запросами вместо исполь­зования объединений или сложных условий OR. Оптимальный выбор зависит от многих дискретных факторов, и только эксперимент поможет решить, какой подход использовать.

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