Разделенная база данных
Проектрируя свои самые первые базы данных в Access, начинающие программисты как правило строят приложения, которые обычно состоят из одного файла базы данных, то есть таблицы, формы, отчеты - все расположены в одном файле mdb. Такая схема может быть удобна лишь тогда, когда база делается что называется "для себя". Но Access так же позволяет кроме локальных приложений баз данных создавать и сетевые. В простейшем случаем это разделенная база данных, которая включает в себя два файла mdb: первый - это файл объектов данных (в нем хранится большинство таблиц), второй - файл объектов приложения (в нем содержатся все оставшиеся объекты базы - формы, запросы, отчеты, страницы доступа к данным, модули VBA, макросы). В этом случае в файле объектов приложения необходимо установить связи с таблицами, хранящимися в файле объектов данных.
При разделении базы данных получают следующие преимущества:
- В однопользовательской среде можно обновлять объекты приложения базы, не оказывая влияния на существующие данные. При этом приложение обновляется простой заменой файла объектов приложения базы. Альтернативой этому может служить такой способ: представьте, что Вы установили неразделенную базу данных, пользователи начали работать с ней, причем постоянно, и тут Вам дают задание, что либо изменить: сделать новый отчет, запрос и т. д. Придется выгонять пользователей, садиться за машину, делать работу. И все это время база будет не рабочей. Конечно, такая ситуация не реальна. Реальнее, что скорее выгонят Вас с работы, чем остановят производство. Поэтому, даже однопользовательские базы данных лучше делать разделенными.
- В многопользовательской среде с одними и теми же данными могут совместно работать все пользователи приложения, поскольку файл объектов данных размещается на файловом сервере. В качестве файлового сервера может выступать общая папка (с открытым для всех доступом) в которой помещают файл объектов данных (база с таблицами).
Надеюсь, что по поводу целесообразности разделения базы данных сомнений нет. Осталось решить вопрос, как же это сделать. Есть два варианта:
- делаем новую пустую базу, жмем в окне базы правой кнопкой, выбираем в контекстном меню "Импорт" или "Файл - Внешние данные - импорт", и далее по диалогу. В результате в базу будут импортированы (скопированы) таблицы. Удаляем таблицы из базы, откуда делался импорт, и подключаем ее к таблицам новой базы.
- делаем разделение базы при помощи мастера: "Сервис - служебные программы - разделение баз данных" и далее по диалогу.
Подключение же к серверу (базы с таблицами) делается очень просто - жмем правой кнопкой в окне базы объектов приложения (там, где формы и все остальное), выбираем в контекстном меню "Связь с таблицами" или "Файл - Внешние данные - Связь с таблицами" и далее по диалогу. В результате в нашей базе появятся ярлыки таблиц, причем со значком стрелки слева, который означает, что таблицы внешние. Ограничение при работе с такими таблицами - нельзя менять их структуру (добавлять, изменять поля и т. д.) в этой базе. Можно только в той, где они созданы (находятся).
Но лучше, если уж решили делать базу разделенной, при проектировании сразу же создавать две базы mdb: в одну помещаем таблицы, в другую все остальное.
Итак, база разделена. Напомню, основное преимущество разделения базы - возможность создания сетевого приложения. Представим: на одном из сетевых компьютеров создаем папку "База", открываем к ней общий доступ (нужно так же открыть доступ и к диску, на котором установлен Access, обычно "С"), и помещаем в нее файл объектов данных (базу с таблицами). На других компьютерах размещаем копии файлов объектов приложения (базу с формами, отчетами и т. д.) и подключаем их к нашему "серверу". Получилось сетевое приложение - много пользователей заносят данные в одну базу. Такое приложение называется "Файл - серверным", так как в качестве "сервера" выступает файл объектов данных.
Но допустим, по каким то причинам месторасположения "сервера" изменилось - папку База переместили. Как только пользователи запустят свои приложения, у них появится сообщение о том, что таблицы не найдены. В этом случае, жмем правой кнопкой по ярлыку таблицы в приложении пользователей, выбираем в контекстном меню "Диспетчер связанных таблиц", помечаем те таблицы, путь к которым нужно обновить, или жмем "Выделить все", затем "ОК" и далее по диалогу.
Все вышеуказанные действия делаются вручную. Но можно ли все это сделать программно?
Автоприсоединение (автолинковка) таблиц
Сначала подумаем, в каких еще случаях, кроме как нежелании вручную нажимать на кнопки, может понадобится автолинковка? Казалось бы, поместил базу на компьютер - "сервер", подключил к ней базы (приложения) пользователей, и не трогай ее (не перемещай). Зачем каждый раз при запуске цеплять таблицы? Дело тут вот в чем:
- Иногда приходится менять месторасположение "файлового сервера". Представьте, 50 пользователей, 50 раз придется бегать к каждому и настраивать новое подключение.
- Предположим, Вы сделали установочный дистрибутив вашего приложения Access - Setup.exe. Откуда вам знать, куда пользователь захочет установить Вашу программу: на "С", "D" или куда то еще? Можно конечно в настройках программы - упаковщика указать, что программа будет ставиться только в "С:/Program Files…". Но такой подход не серьезен, и лишь покажет Ваш непрофессионализм.
Стало быть, деваться некуда, придется цепляться. Что для этого понадобится?
Самое главное - это CurrentProject.Path (текущий проект - путь): оказывается, Access сам знает, куда его установили. Далее понадобятся программные методы работы с таблицами (чтение, запись, удаление данных) - ведь нужно не просто определить, куда установили приложение, но и сохранить его путь в таблице, и затем "подцепить" их по этому пути. Делается это при помощи объектной модели доступа к данным DAO - Data Access Objects. Объекты доступа к данным создавались, как объектно-ориентированный интерфейс для ядра баз данных Jet фирмы Microsoft как раз для того, чтобы можно было программно вносить, изменять, удалять данные в таблицах.
Общая схема работы подключения:
при запуске приложения запускается макрос AutoExec - чтобы он запускался именно при запуске, он должен называться AutoExec - это зарезервированное имя в Access. Макрос в свою очередь запускает функцию SetReferences () из модуля AutoPatch, которая собственно и производит автолинковку таблиц. Далее макрос запускает форму frmStart - стартовую форму приложения.
Путь базы сохраняется в таблице tSystemPath - Pname. Имена таблиц, которые нужно присоединить - в таблице tSystemTables - Tname. Если вы будете применять этот пример в своих проектах, Вам нужно будет записать туда имена своих таблиц.
В данном примере при запуске приложения помимо автолинковки делается еще одно важное дело: записывается путь к папке с резервными копиями базы (об этом чуть ниже). Это так называемые данные настройки приложения. Их может быть много: к примеру, каталог выгрузки снимков отчетов, каталог шаблонов .dot и т. д. Чтобы после запуска, приложение было работоспособным, нужно все эти настройки определить и сохранить в соответствующих таблицах, в данном случае tAdminCop.
Резервное копирование базы данных
Хотя Access и считается достаточно надежной системой, но и у нее бывают сбои и базы "рушатся" - нет в мире совершенства. А потому считается хорошим тоном сделать сервис - сохранение резервных копий базы. Действительно, зачем рисковать?
Для этого понадобятся методы работы с файловой системой Windows - модуль FileSystem и функции работы с файлами: fDeleteFile, fCopyFile. Названия говорят сами за себя. Чтобы пользователь мог указывать/создавать каталог для сохранения резервных копий понадобится GetDirFolder - функция открытия диалогового окна выбора каталога (папки).
Непосредственно копирование производится при помощи процедуры sCopBase в модуле формы frmStart. Причем, сначала проверяется наличие каталога для сохранения копии базы, наличие самой базы - функции IsFolderName, IsFileName.
Имена копий базы задаются с указанием даты и времени копирования.
Пример, как это все работает, Вы можете скачать ниже.