Отправляет email-рассылки с помощью сервиса Sendsay

Программирование и готовые решения

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 5.410 RSS
←   Январь 2007   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://blog.leadersoft.ru
Открыта: 29-08-2000

Автор
leadersoft.ru

Статистика

5.410 подписчиков
0 за неделю
←   Все выпуски   →

Microsoft Access - программирование и готовые решения


Выпуск 55. Материалы для начинающих (1 урок)

Подписка: "Access 2000 - программирование и готовые решения"
Дата:         14.01.2007
Автор:      Парусников Алексей
Сайт:        http://www.accessoft.ru под редакцией с http://www.leadersoft.ru/
Новые материалы: автолинковка
На сайте AccesSoft начинается публикация статей для начинающих, посвященных разработке приложений на Access


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

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

Создавая свои первые базы данных в Access, начинающие разработчики обычно строят приложения, которые состоят из одного файла базы данных, то есть таблицы и формы расположены в одном и том же файле mdb. Такая компоновка может быть удобна лишь в том случае, когда база делается что называется «для себя». Но Access позволяет помимо локальных приложений создавать и сетевые. Простейшим случаем такого приложения является разделенная база данных, включающая в себя два файла mdb: первый — файл объектов данных (в нем хранятся таблицы), второй — файл объектов приложения (в нем хранятся все остальные объекты — формы, запросы, отчеты, страницы доступа к данным, макросы и модули VBA). При этом в файле объектов приложения устанавливаются связи с таблицами, хранящимися в файле объектов данных.
Разделение базы данных дает следующие преимущества:

  1. В однопользовательской среде можно обновлять объекты приложения, не оказывая влияния на существующие данные. При этом приложение обновляется простой заменой файла объектов приложения. Альтернативой этому может служить такой способ: представьте, что Вы установили неразделенную базу данных, пользователи начали работать с ней, причем постоянно и тут Вам дают задание, что либо изменить: сделать новый отчет, запрос и т. д. Придется выгонять пользователей, садиться за машину, делать работу. И все это время база будет не рабочей. Конечно, такая ситуация не реальна. Реальнее, что скорее выгонят Вас с работы, чем остановят производство. Поэтому, даже однопользовательские базы лучше делать разделенными.
  2. В многопользовательской среде с одними и теми же данными могут совместно работать все пользователи приложения, поскольку файл объектов данных размещается на файловом сервере. В качестве файлового сервера может выступать общая папка (с открытым для всех доступом) в которой помещают файл объектов данных (база с таблицами).

Надеюсь, что по поводу целесообразности разделения базы данных сомнений нет. Осталось решить вопрос, как же это сделать. Есть два варианта:

  1. делаем новую пустую базу, жмем в окне базы правой кнопкой, выбираем в контекстном меню «Импорт» или «Файл – Внешние данные – импорт»,  и далее по диалогу. В результате в базу будут импортированы (скопированы) таблицы. Удаляем таблицы из базы, откуда делался импорт, и подключаем ее к таблицам новой базы.
  2. делаем разделение базы при помощи мастера: «Сервис – служебные программы – разделение баз данных» и далее по диалогу.

Подключение же к «серверу» (базы с таблицами) делается очень просто – жмем правой кнопкой в окне базы объектов приложения (там, где формы и все остальное), выбираем в контекстном меню «Связь с таблицами» или «Файл – Внешние данные – Связь с таблицами» и далее по диалогу. В результате в нашей базе появятся ярлыки таблиц, причем со значком стрелки слева, который означает, что таблицы внешние. Ограничение при работе с такими таблицами – нельзя менять их структуру (добавлять, изменять поля и т. д.) в этой базе. Можно только в той, где они созданы (находятся).
Но лучше, если уж решили делать базу разделенной, при проектировании сразу же создавать две базы 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.
    Имена копий базы задаются с указанием даты и времени копирования.

    Пример с открытым кодом, как все вышесказанное работает, Вы можете скачать нажав на эту ссылку....
    В избранное