Разделенная база данных.

Создавая свои первые базы данных в 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.
Имена копий базы задаются с указанием даты и времени копирования.

Пример с открытым кодом, как все вышесказанное работает, Вы можете скачать нажав на эту ссылку http://www.accessoft.ru/Text/Text1.html.
Парусников Алексей Владимирович