Если база данных MS Access начинает «тормозить», медленно открываются формы, отчеты, виной тому чаще всего являются тяжелые запросы. Первым делом необходимо определить над каким именно запросом задумывается Access, а затем приступить к его оптимизации. Во «взрослых» базах данных, таких как Oracle, MS SQL Server, PostgreSQL, MySql есть документированные средства, позволяющие взглянуть на выполнение запроса глазами SQL-сервера. Я говорю о плане выполнения запроса.

А как же в Access? Неужели разработчики не предусмотрели возможность просмотра плана выполнения запроса?

Оказалось такая возможность есть, просто она недокументированная. Если в разделе реестра
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Debug] создать строковый параметр JETSHOWPLAN и присвоить ему значение ON, то это заставит Access (после перезапуска) создавать текстовый файл showplan.out в папке Мои документы, в котором будет содержаться план выполнения запросов.

Построение плана выполнения запросов происходит в момент компиляции последних. Существующие запросы уже, как правило, скомпилированные. Чтобы заставить Access перекомпилировать запрос, нужно его изменить (как вариант открыть запрос, перейти в режим SQL и добавить пробел в конце), сохранить и выполнить. (далее…)

В MS Access получить количество записей в таблице можно множеством способов. Вопрос в том, какой способ самый быстрый.

На время получения результата могут влиять многие факторы:

• находится файл базы данных на локальном или сетевом диске;
• используются обычные или связанные таблицы;
• используются ли в таблицах индексы;
• количество записей в таблицах.

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

Я выбрал таблицу, содержащую порядка 10 млн. записей (индексы используются). Создал вторую базу данных, к которой прилинковал выбранную таблицу – необходимо для тестирования подключаемых таблиц. Вторую базу данных разместил на другом компьютере 100-мегобитной локальной сети.

Тестировались следующие методы получения количества строк в таблице:

1. Агрегатная функция VBA DCount.
2. Агрегатная функция SQL Count.
3. Свойство Recordcount объекта DAO, возвращаемое функцией OpenRecordset.

Будут использованы разные варианты. Результаты тестирования привожу в таблице:

lntCount = DCount("*", "MyTable")

lntCount = DCount("ID", "MyTable")

lntCount = CurrentDb.OpenRecordset _
("SELECT Count(*) AS [CountOfID] FROM MyTable;") _
![CountOfID]

lntCount = CurrentDb.OpenRecordset _
("SELECT Count([ID]) AS [CountALL] FROM MyTable;") _
![CountALL])

lntCount = CurrentDb.OpenRecordset("Count_Query") _
![CountOfID]

lntCount = CurrentDb. _
OpenRecordset("Mytable").RecordCount

lntCount = OpenDatabase _
("c:\My Documents\LinkedDatabase.mdb"). _
OpenRecordset("Mytable").RecordCount

Как выяснилось, использование «*» или название поля в агрегатных функциях DCount и Count на времени получения количества строк сказывается незначительно. Также не намного отличаются результаты для «родных» и связанных таблиц. Ну а свойство RecordCount объекта Recordset приятно удивило. Беру на замету!

Профессионально разработанный пользовательский интерфейс должен одинаково хорошо смотреться и быть удобным для пользователя независимо от того, на каком дисплее он отображается. Давайте взглянем на изображенную ниже форму MS Access:

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

Попытаемся исправить ситуацию. (далее…)

Достался в наследство  проект MS Access 2003, который я должен дорабатывать и сопровождать. В процессе работы обнаружился один досадный глюк: в VBA редакторе отладчик не останавливается на точке останова (breakpoint).  Первое что пришло в голову: а нет ли ошибки в коде до точки останова. Проверил, функция отрабатывает нормально, результат возвращает корректный. Далее замечаю, что не работают не только точки останова, но отладка в целом. Пройтись отладчиком по F8 шаг за шагом по каждой строке функции не получается, вместо этого вся функция выполняется целиком.

В редакторе  Microsoft Visual Basic  лезу в Tools -> Options. На закладке General в группе переключателей Error  Trapping выбираю Break on All Errors. Устанавливаю точку останова, запускаю отладку — не срабатывает.

Оказалось, что отучить MS Access 2003 игнорировать точки останова и режим отладки возможно.

(далее…)