Данная статья адресована в первую очередь тем, кого, в основном, устраивают возможности 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 на самом деле?

В основе Access лежит ядро баз данных Microsoft Jet. Объекты Access, доступные из VBA (в Access 2000 – из VB), являются на самом деле объектами ядра Jet. Те же обработчики событий в формах, например, мы имеем возможность писать благодаря тому, что объект ядра Jet Form поддерживает эти события. Ядро Jet имеет невысокие по сравнению с большими СУБД требования к ресурсам системы, обладая при этом достаточно большим потенциалом. Именно поэтому Access выглядит таким мобильным и годится для решения многих практических задач на достаточно современном уровне с минимальным количеством накладных расходов.

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

И в то же время, возможность использовать триггеры в Access 2000 есть. Но не радуйтесь, поклонники Access 97 и более ранних версий. Сейчас я напишу, какой ценой это достигается. Microsoft теперь считает, что время Jet прошло и настала очередь больших корпоративных СУБД. Таких как SQL Server 7.0. Предусмотрено постепенное вытеснение Jet технологиями клиент-сервер. Появилось новое ядро баз данных MSDE (Microsoft Database Engine), очень тесно совместимое с SQL Server 7.0, практически это сильно усеченный SQL Server. Работая через это ядро можно хранить данные в формате SQL Server 7.0. Именно это рекомендуется делать тем, кто хочет иметь триггеры в Access 2000.

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

1. Установить MSDE, который не является частью MS Office 2000, но имеется на CD#1 (нужен Office 2000 Professional, Developer или Corporative Edition): \Sql\X86\Setup\Setupsql.exe. MSDE занимает около 55 MB на диске при локальной установке + кое-что он копирует в системные директории. Его можно также установить на удаленный компьютер, но какая-то часть компонентов все равно при этом должна находиться на Вашем компьютере.
2. Загрузить в Access 2000 Вашу БД, которую Вы хотите конвертировать в формат SQL Server 7.0, и запустить Upsizing Wizard (найдете в меню Tools | Database Utilities). Предварительно очень рекомендуется почитать HELP. Wizard сделает все, что нужно, Ваша БД будет храниться далее в формате MS SQL Server 7.0, а не в mdb-файле. В Access вместо mdb Вы будете загружать файл проекта adp.
3. Это, собственно, все.

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

Вы получаете возможность использовать виды (views), триггеры (triggers) и хранимые процедуры (stored procedures) SQL Server, редактируя их непосредственно из Access. Повышается уровень безопасности транзакций, появляются еще кое-какие плюсы, которые разработчика под Access обычно мало волнуют. Поскольку Ваша БД становится полностью совместима с SQL Server, Вы можете пользоваться всеми его прибабахами. При этом у Вас остается весь инструментарий Access по разработке пользовательского интерфейса. Вы можете использовать также защиту данных на уровне SQL Server. Таблица Access в режиме дизайна начинает выглядеть так, как в Enterprise Manager SQL Server 7.0. Исчезает также вкладка Queries, вместо нее появляются вкладки Views и Stored Procedures.

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

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

Ваш коментарий будет первым

Добавить коментарий
Имя:
E-mail
Коментарий:
Код:*