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

Я работаю с Access примерно с того момента, когда появился Microsoft Office 97, на любительском уровне. Считаю ее почти идеальной СУБД класса desktop. Посудите сами: таблицы, формы, отчеты, запросы, VBA, защита данных – и все это практически даром. В том смысле, что кроме Access не нужно ничего более для создания полноценного DB приложения, ориентированного на небольшое количество пользователей. Все типичные операции оформлены в виде визардов. Программист имеет возможность сосредоточиться на сути своей задачи, пользовательский интерфейс же разрабатывается легко и быстро. Короче, 100 в одном.

Но есть один неприятный момент. Реальная БД всегда содержит какую-нибудь особенность, которая не вписывается в схему возможных ограничений Access на значение конкретного поля или совокупности полей в записи таблицы. Кое-какие ограничения, конечно, задать можно, но их сложность ограничивается сложностью выражения, которое Access способен переварить в качестве такого ограничения. Все, кто что-либо проектировал в Access, знают, что никакой сложной обработки, вроде обращения к другим таблицам, там не может быть и в помине.

Пожелание разработчика в целом можно сформулировать так: "хочу иметь пользовательскую функцию, которая срабатывает всякий раз, когда данные в таблице меняются (точнее – хотят измениться!), такую, которая может либо запретить изменение, либо что-то в нем скорректировать, и такую, которую никак нельзя обойти". В современных СУБД такая функция называется триггером (trigger). Триггеры есть в Oracle, в SQL Server. С другими СУБД я пока в жизни не встречался, наверняка триггеры есть и где-то еще.

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

Часто лучше потерять все данные сразу, чем иметь ошибочные данные и думать, что они правильные. Поэтому проблема контроля ввода данных в таблицы является весьма и весьма насущной.

Когда у меня эта проблема встала очень остро, я кинулся искать решение. Обратился на несколько сайтов, в том числе на сайт Валерия Титова, он мне сообщил, что Microsoft Access 2000 содержит триггеры, но в деталях он еще не разбирался. Я в тот момент работал с Access 97. Валерий (публичное ему спасибо) прислал мне несколько статей, с которых можно начать изучение вопроса. Две из них серьезно прояснили ситуацию, в особенности статья Билла Демаса "Обзор механизмов обработки данных Microsoft Access 2000".

Так как же обстоят дела с триггерами в MS Access 2000 на самом деле?

Так вот: на уровне ядра Jet в Microsoft Access 2000 триггеров нет! Хотя это решение напрашивалось само собой уже давно, Microsoft не стала наращивать Jet до триггеров. На мой взгляд, это продиктовано чисто коммерческими соображениями и связано с желанием Microsoft стремительно продвигать на рынок технологии, использующие SQL Server 7.0. Ведь если довести до ума Access, то многие пользователи к SQL Server не обратятся никогда в жизни. А на самом деле очень логично было бы разрешить, скажем, объекту Jet TableDef иметь при себе модуль (так же как у объекта Form), в котором можно было бы писать обработчики типа BeforeInsert, BeforeDelete или OnUpdate. Но, увы, увы... Да, кстати, в документации по Access триггером иногда называется группа кнопок, выполняющих функции переключателей – так это не те триггеры, не те...

Коротко напишу, что надо сделать, чтобы заставить MS Access 2000 работать через MSDE.

Какие выгоды из всего этого?

Какие минусы?

Система становится заметно более тормозной. По крайней мере я это сильно ощущаю при конфигурации Pentium 166 MMX / 64 RAM / WinNT 4.0 SP 4. Для распространения Вашего приложения Вам придется таскать с собой инсталлятор MSDE. Access – Ваш любимый, маленький, компактный, мобильный – превращается в монстра. Хорошо для корпоративных решений, но совсем плохо для настольных баз данных. Чтобы писать триггеры, ради которых Вы все это и затевали, Вам придется освоить язык, на котором они пишутся – Transact-SQL. Чтобы полноценно использовать предоставленные Вам возможности, нужно знать SQL Server 7.0. А если Вы знаете SQL Server 7.0, то Вы скорее всего, выросли из Access. Хотя в общем, одно другому не мешает.

Дмитрий Леонов.