Рассылка статей

      Программируя в Access не стоит забывать, что он является частью пакета Microsoft Office, поэтому один из плюсов MS Access как средства разработки -  интегрированность с такими мощными приложениями как Word, Excel, PowerPoint, Outlook. Конечно, получить доступ к ним можно не только при помощи Access, но начиная с версии MS Office 2000, все они имеют один общий язык программирования – VBA. И в этой серии статей рассмотрим примеры использования такой интеграции, или как ее еще называют – автоматизации.

      Автоматизация (ранее известная как OLE-автоматизация — OLE Automation) — это одно из наиболее важных средств технологии ActiveX, позволяющее программно управлять объектами из других приложений. И это основное средство, с помощью которого можно интегрировать функциональные возможности различных приложений.

Клиенты и серверы автоматизации

      При интеграции двух приложений одно предоставляет свои объекты для использования, а другое использует объекты первого приложения.

• Приложение, объекты которого доступны для других приложений, называется сервером автоматизации (иногда его еще называют компонентом)

• Приложение, которое использует объекты другого приложения, называется клиентом (или контроллером) автоматизации. Объекты, которые доступны для других приложений, называют объектами автоматизации

      Через объекты автоматизации приложение – сервер открывает доступ другим программам к тем своим функциям, которые могут быть им полезны. Например, текстовый редактор может открывать другим программам доступ к проверке орфографии, служба связи – доступ к созданию и отправке сообщений. Это позволяет разработчикам ускорить процесс разработки своих приложений, благодаря использованию готовых функций сервера.

      Для программного управления объектом автоматизации из любого приложения Microsoft Office необходимо:

1. Установить ссылку на библиотеку объектов приложения-сервера автоматизации.
2. Создать объект нужного класса.
3. Осуществить все необходимые действия над объектом, обращаясь к его свойствам и методам.
4. Закрыть объект.

      Но можно использовать объекты сервера автоматизации и не устанавливая ссылку на конкретную библиотеку объектов, однако в этом случае программа будет работать медленнее. Это связано с тем, что после установки ссылки на библиотеку, при объявлении объектной переменной, можно указать ее конкретный тип, если же ссылка отсутствует, то для этой переменной придется указать обобщенный тип — Object.

Microsoft Access как клиент автоматизации

      Чтобы создать объект для использования в операциях автоматизации, нужно сначала создать экземпляр его класса и присвоить ссылку на него объектной переменной. Однако создать можно не любой объект из объектной модели приложения-сервера, а только глобальные объекты. Таким глобальным объекто�� для всех объектных моделей приложений семейства Microsoft Office является объект Application, который находится на вершине иерархии объектов.

      Для того чтобы узнать, какие свойства моделей объектов являются глобальными, можно воспользоваться окном просмотра объектов в редакторе VBA – Object Browser (запускается например так: откройте любой модуль и нажмите F2).
Потом выберите в раскрывающемся списке Project/Dbrary нужную библиотеку, а затем выберите элемент <globals> в списке Classes.
      Существует несколько способов создания экземпляра класса объекта.

1. С помощью ключевого слова New

Это ключевое слово описывает переменную типа Object и одновременно устанавливает ссылку на новый экземпляр класса объекта.

Dim app As New Excel.Application

При использовании ключевого слова New для создания нового экземпляра класса Application запускается соответствующее приложение (например, Word или Excel). Если это приложение уже запущено, то, чтобы не запускать второй экземпляр, лучше использовать для создания нового экземпляра класса функцию GetObject ()

Чтобы использовать ключевое слово New для создания экземпляра класса объекта автоматизации, необходимо предварительно добавить ссылку библиотеки объектов приложения сервера в диалоговом окне редактора VBA References (Ссылки).

Пример использования:

Sub PowerPointOpenFile_Click()
On Error GoTo Err_
Dim strAppName As String
Dim app As New PowerPoint.Application ‘ создаем экземпляр класса
      strAppName = CurrentProject.Path & "\Презентация1.ppt" ‘ указываем путь к файлу Презентация1.ppt
      With app
            .Visible = True ‘ «проявляем» PowerPoint
            .Presentations.Open strAppName ‘ открываем файл Презентация1.ppt
      End With
      Set app = Nothing ‘ освобождаем переменную
Exit_:
      Exit Sub
Err_:
      MsgBox Err.Description
      Resume Exit_
End Sub

2. С помощью функции CreateObject()

      Функция CreateObject () создает ссылку на новый экземпляр класса автоматизированного объекта. Значение, возвращаемое этой функцией, должно быть присвоено объектной переменной с помощью оператора Set. Например, названным оператором открывается приложение Word, и ссылка на него присваивается объектной переменной docobj. При этом, даже если Word уже был открыт, будет запущен еще один его экземпляр:

Set app = CreateObject ("Excel.Application")

      Объектная переменная в данном случае может быть объявлена как Object, и тогда ссылку на библиотеку объектов Microsoft Word устанавливать не надо. А может быть объявлена так:

Dim app As Excel.Application

      В этом случае должна быть обязательно установлена ссылка на библиотеку объектов Microsoft Word **.0 Object Library (** показывает, что для разных версий офиса разные значения: 10.0, 11.0, 12.0 – для соответственно офисов ХР, 2003, 2007). Если на компьютере установлено несколько версий Microsoft Office, то можно указать номер версии приложения, которое будет использоваться при автоматизации, например:

Set app = CreateObject("Excel.Application.11")

Пример использования функции:

Sub ExcelOpenFile()
On Error GoTo Err_
Dim strAppName As String
Dim app As Excel.Application
      strAppName = CurrentProject.Path & "\Книга1.xls" ‘ указываем путь к файлу Книга1.xls
      Set app = CreateObject("Excel.Application")  ‘ создаем экземпляр класса
      With app
            .Visible = True ‘ «проявляем» Excel
            .Workbooks.Open strAppName         ‘ открываем файл Книга1.xls
      End With
      Set app = Nothing       ‘ освобождаем переменную
Exit_:
      Exit Sub
Err_:
      MsgBox Err.Description
      Resume Exit_
End Sub

3. С помощью функции GetObject()

      Этот способ используется для того, чтобы получить ссылку на уже существующий экземпляр класса, т. е. для доступа к существующим документам, хранящимся в файлах, или для доступа к объекту Application уже запущенного приложения-сервера. Функция Getobject () имеет следующий синтаксис:

Set <объектнаяПеременная> = Getobject([<путь>][,<класс>])

      Обязательно должен быть указан хотя бы один из аргументов функции!

      Рассмотрим три варианта написания функции:

• Set app = GetObject(, "Excel.Application")

      здесь опускается первый параметр – тогда функция работает подобно двум вышесказанным – просто для создания экземпляра класса объекта.

• Set app = GetObject("C:\Baze\ Книга1.xls", "Excel.Application")

      здесь указаны оба параметра – путь к файлу и имя приложения. В этом случае запускается файл Лист.xls

• Set app = GetObject("C:\Baze\ Книга1.xls")

      здесь второй аргумент может быть опущен, если в реестре Windows существует связка расширения файла с объектом приложения. Например, в случае Microsoft Excel файлы xls по умолчанию имеют объектный тип Excel.Workbook. Это означает, что если не указывать аргумент <класс>, то будет создана ссылка на объект Workbook, представленный указанным в первом аргументе файлом.

Пример использования функции:

Sub WordOpenFile()
On Error GoTo Err_
Dim strAppName As String
Dim app As Word.Application
      strAppName = CurrentProject.Path & "\Doc1.doc"
      Set app = GetObject("", "Word.Application")
      With app
            .Visible = True
            .Documents.Open strAppName
      End With
      Set app = Nothing
Exit_:
      Exit Sub
Err_:
      MsgBox Err.Description
      Resume Exit_
End Sub

      Для того чтобы легче было создавать код для работы с объектами Word или Excel, вспомните о таком замечательном средстве этих приложений, как запись макросов. С помощью записи макросов можно выполнить все необходимые действия, используя интерфейс пользователя, затем просмотреть сгенерированный код VBA и встроить этот код в свою процедуру VBA, только слегка подправив его.

      Например: открываем файл excel, выбираем Сервис – Макрос – Начать запись. В появившемся диалоговом окне присваиваем имя макросу и жмем «ОК». Далее делаем свои дела – форматируем ячейки, изменяем данные – все что угодно. Последовательность действий записывается в специальный модуль в виде команд VBA. Жмем остановить запись. Затем Сервис – Макрос – Редактор Visual Basic и в группе Modules находим новый модуль. Открываем и смотрим, как все что вы делали выглядит на VBA.

      После того как все необходимые операции с объектами приложения-сервера выполнены, эти объекты следует закрыть, чтобы освободить занимаемую ими память. Большинство объектов поддерживают для этого методы close или Quit. Кроме того, следует освободить объектную переменную, присвоив ей значение Nothing.

      В прилагаемом к статье примере показаны варианты открытия документов Word, Excel, Power Point. Для разнообразия для каждого документа  использован один из трех способов открытия. Но, разумеется, любой из документов можно открыть любым из способов.

PS. Нужна будет ссылка на нужную библиотеку в VBA

      Прежде чем приступать к защите базы с помощью файла рабочей группы, следует определиться: будем защищать обе части приложения (файл с данными и файл объектов) или только файл с данными? Защищать интерфейсную имеет смысл, если Вы хотите ограничить доступ пользователей к макросам и запросам (запретить их редактирование). Про формы и отчеты речь не идет, ведь само собой разумеется, что база будет предъявлена пользователю в формате mde. Если же это не является проблемой,  например, все запросы прописаны в свойствах форм и отчетов – то достаточно будет установить защиту только на серверную часть. В этом случае базу будет проще администрировать.

      Для установки защиты используют специальный мастер. Открываем файл данных – Сервер.mdb. Затем Сервис – Защита – Мастер. Откроется диалоговое окно, где первым делом предлагается выбрать: создать или изменить текущий файл рабочей группы. Нам нужно «Создать». Жмем далее. В открывшемся окне в поле «Имя файла» автоматически прописывается путь к файлу рабочих групп – по умолчанию, в том же каталоге, что и Сервер.mdb. Обратим внимание на поле «Код рабочей группы». Это уникальный идентификатор группы из случайно набранной буквенно-цифровой комбинации.

Его обязательно нужно сохранить!

      Дело в том, что при потере или порче файла рабочих групп доступ к базе станет не возможен (насчет хакерских методов промолчу). В конце все процедуры мастер предложит Вам создать отчет о проделанной работе  - там среди прочего и будет этот код. Также оставим галочку «создать ярлык для защищенной базы». В предыдущей части статьи говорилось об этом ярлыке. Речь шла о том, чтобы запускать базу через него, а не подключать созданный mdw ко всем проектам Access. Раз уж мастер взялся за дело, пусть он и делает ярлык. Жмем далее.

      На следующей вкладке предлагается выделить объекты, которые необходимо защищать. В большинстве случаев, если уж ставить защиту, так на все, что собственно и делается по умолчанию. Поэтому просто жмем далее.

      Теперь мастер предлагает создать рабочие группы, причем права доступа по ним уже заранее распределены. Можете выбрать какие либо из них, а можете проехать дальше. Лично я всегда сам создаю себе группы, но как говорится дело вкуса. Жмем далее.

      На этой вкладке предлагается группе Users назначить ограниченные права. Смысл тут в том, что как уже говорилось в первой части статьи, все базы Access в действительности уже подключены к стандартному файлу рабочих групп, просто права у всех пользователей (группа Users) полные, как у администратора. А при «установке защиты» создается новый файл группы или изменяется стандартный. Вообще, в любом файле групп всегда будут присутствовать как минимум две группы: Admins и Users. Это и понятно: во всякой системе защиты «входящий» в простейшем случае должен быть опознан как простой пользователь или администратор. Удалить эти два понятия никак нельзя, иначе теряет смысл защита – как узнать, кто пришел? Хотя начинающие разработчики иногда пытаются удалить «юзеров», а те не удаляются…

      Заметим, мастер предупреждает, чтобы не отдавали «юзерам» права без особой надобности, ведь раз такая группа есть во ВСЕХ группах, то назначая ей права, вы автоматически назначаете эти права по умолчанию для всех файлов mdw. Говоря проще, если дать группе Users полные права, то для обхода защиты достаточно создать новый файл mdw и зайти под именем пользователя группы Users. Поэтому чаще всего эту вкладку также проезжаем.

      Теперь добрались до создания своих админов и юзеров. По умолчанию там уже есть админ – можете заменить его на своего, если ему не доверяете. Для этого выбираем в списке слева «Добавить пользователя», задаем ему имя (например Пупкин), пароль и жмем «Добавить пользователя в список». Теперь можно прогнать старого админа – выделяем его и жмем «Удалить пользователя из списка». Теперь наш Пупкин автоматически стал админом (потому как других все равно нет). Чтобы убедиться в этом, переходим на следующую вкладку и видим, что в группе Admins (администраторы) присутствует наш человек. Жмем далее.

      Теперь осталось только указать, куда сохранить резервную копию незащищенной базы. Это на случай, если вдруг вы передумаете и решите вернуть все «как было». Access создает копию базы, только меняет у нее расширение на .bak. Видимо для того, чтобы никто не догадался, что это не защищенная база. Жмем готово.

      База шифруется и появляется отчет о проделанной работе. Еще раз напомню – его обязательно нужно сохранить. Если вдруг файл групп mdw куда то денется или сломается, чтобы получить доступ к базе нужно будет создать его заново, указав при создании его старый код рабочей группы – стереть тот, что предлагает мастер, и поставить свой.

В результате всего получилось следующее:

1. Появился новый файл рабочих групп - Security.mdw (в Access 2002 он по умолчанию называется Secured.mdw)
2. Все объекты базы Сервер.mdb (таблицы) «прошились» через файл рабочих групп
3. Появилась копия базы – Сервер.bak
4. На рабочем столе появился ярлык подключения к базе – Сервер.lnk

      Теперь попробуем запустить базу обычным способом – двойным кликом. В результате: «Остутсвуют разрешения на использование объекта Сервер.mdb и т. д.». То же самое увидит и злоумышленник, пытающийся добраться до ваших данных в базе. Стало быть защита работает. Теперь запустим через ярлык – появится форма авторизации. Введем в ней логин «Пупкин» и пароль, которые ему задали – база открывается.

      Итак, база защита, но из всех пользователей там только админ Пупкин. Значит будем создавать пользователей и группы. Запускаем через ярлык базу и жмем Сервис – Защита – Пользователи и группы. На первой вкладке создаем пользователей, на второй - группы пользователей. С этим думаю проблем не будет: жмем «Создать» и далее по диалогу. Замечу только, что имена лучше давать как цифры. Дело в том, что как известно встречаются однофамильцы, а вот одинаковых цифр не существует.

      Если пользователей достаточно много, то имеет смысл создать группы, чтобы объединить их. В каждой группе может быть несколько пользователей. Права доступа группы автоматически назначаются членам группы. Тем самым упрощается администрирование базы данных. Переходим на вторую вкладку и создаем необходимые нам группы. Затем возвращаемся на первую. Здесь мы видим, что в списке групп кроме стандартных admins и users появились новые. Чтобы зачислить в них наших пользователей, выберем из списка пользователя, выделим группу и жмем добавить. Обратим внимание, что наш админ Пупкин должен обязательно присутствовать в группе администраторов (admins). Иначе он не будет админом. Соответственно, всех остальных это не касается.

      После создания пользователей и распределения их по группам осталось задать им пароль входа – это делается на последней вкладке.

Пароль пользователя может изменить только сам пользователь, то есть тот, кто зайдет в программу под его именем!

      Теперь настала пора задуматься о правах доступа. Для этого следует тщательно продумать, кто из пользователей к чему должен иметь доступ. Тут есть несколько решений.
К сожалению, в Access не возможно устанавливать доступ на поля таблиц, а можно только ко всей таблице. Поэтому, для случая, когда к данным одной таблицы разные пользователи должны иметь разный доступ, придется хитрить. Например:

1. «распилить» таблицу на части и связать их соотношением один к одному. Это как раз тот случай, когда такая вообщем то странная связь имеет смысл.
2. Сделать разные формы для разных пользователей и запускать их для каждого свою. Чтобы узнать кто есть кто, можно воспользоваться простой процедурой:

IF CurrentUser = “1” Then …

Но такой вариант не дает доступа к данным через формы, но ничто не мешает пользователю «залезть» напрямую в Сервер.mdb.

Изменять уровень доступа может только администратор (admin) – член группы admins!

      То есть для изменения уровня доступа для пользователей необходимо зайти в серверную часть программы под именем администратора (в нашем случае «Пупкин»). Затем выбрать: Сервис – Защита – Разрешения. Можно устанавливать доступ для группы, а можно для каждого пользователя отдельно. В случае с группами при создании нового пользователя, чтобы назначить ему права доступа, достаточно поместить его в соответствующую группу. Поэтому мы будем ставить доступы для групп.

      Для этого на вкладке «Разрешения» нужно переключиться на «группы» и в списке «Пользователь и группы» выбрать необходимую группу. В поле со списком «Тип объекта» выбрать необходимый тип объекта базы данных. В списке «Имя объекта» выбрать объект и в списке «Разрешения» проставить уровень доступа к объекту.

Не экспериментируйте с правами доступа администратор (admin) – иначе Вы, как администратор, может закрыть базу от самого себя!

      Как уже говорилось, вся информация о защите базы храниться в зашифрованном виде в файле рабочих групп - Security.mdw. Перед любыми действиями по изменению уровня доступа или смены паролей рекомендуется сделать резервную копию этого файла и хранить его в надежном месте на внешнем носителе. Тем самым будет возможность вернуть изменения, подключив к базе сохраненную копию Security.mdw.

При потере или порче файла рабочих групп Security.mdw доступ к базе данных станет не возможным!

      Это еще одна причина, по которой рекомендуется сохранять копию Security.mdw на внешнем носителе в надежном месте. В то же время, при попытке открыть серверную часть программы, в которой хранится информация базы данных – файл Сервер.mdb, минуя авторизацию, или говоря проще, при похищении базы злоумышленниками, получить доступ к данным без Security.mdw так же не возможно.

      Кроме ограничения доступа к данным, можно использовать такую защиту и для ведения лог. журнала действий пользователей, позволяющее проследить дату и время создания записи, а так же кем и когда последний раз она была изменена. Для этого в каждой таблице нужно создать поля, в которые автоматически записываются соответствующие данные:

1. Дата создания – дата и время создания записи.
2. Дата изменения – дата и время изменения записи.
3. Изменил – имя пользователя, изменившего запись.

      Запись делается при помощи перехвата события формы «Внесены изменения»

Private Sub Form_Dirty(Cancel As Integer)
      [ДатаИзменения] = Date + Time
      [Изменил] = CurrentUser
End Sub

      А дату создания можно аналогично задать в таблице как дату по умолчанию: Date()+Time() Чтобы данные отображались в расширенном формате, нужно будет установить в таблице формат поля как dd.mm.yy.hh.nn

P.S. Дополнение к статье от Leadersoft.ru Однажды руководитель компании, занимающейся финансовыми вопросами сделал запрос по электронной почте с заявкой вскрыть пароль к базе данной защищенной system.mdw. База эта была разработана ими, но они потеряли пароль и теперь не имеют доступа к файлу mdb. Мне показалась работа эта простой, за нее обещали хорошо заплатить, особых условий не было, но нужно было сделать все за неделю. Но вот, что произошло ...

Конференция: Microsoft Access

Вопрос:  Поиск в поле со списком?
Тема:      Люди!!!! Помогите ламмеру!!! Как сделать переход на определённую запись в форме при помощи поля со списком. Ответы из серии откройте форму "Сотрудники" из учебной базы "Борей" не канают (то есть всё работает но только в Борее а не в моей базе) Пробовал всё : и модули импортировал и создавал при помощи мастера поле со списком (но там в первом окне всего 2!!!!! опции 1. источник запрос или таблица и 2.Фиксированный набор записей!!!! Надо что-то писать в AfterUpdate, но что???? Или может макрос какой???? PLEASE!!!!! HELP!!!!

P.S. среда MS ACCESS 2003

Универсальность  DotNetNuke - это открытый исходный код для создания web приложений. Можно сказать, что это идеальная машина для создания управления интернет и интранет проектами.

Легкость – DotNetNuke специально разработан таким образом, чтобы облегчить дизайнерам порталов легко управлять всеми аспектами их проектов. Специальные помощники, иконки и другой пользовательский интерфейс позволяют легко достигать нужного результата.

Мощность –  DotNetNuke поддерживает множество порталов и сайтов, используя всего одну установку.  Административные функции разделены между хостом портала  и другими сайтами, страницами и объектами. Он позволяет администраторам управлять несколькими сайтами одновременно, каждый из которых может иметь свой дизайн в зависимости от взглядов разработчика.

Богатство инструментов – DotNetNuke включает в себя много инструментов проектирования, обеспечивая различные функциональные возможности сайтов. Например, хостинг, проектирование, содержание и безопасность  легко управляются через эти инструменты. 

Поддержка - DotNetNuke поддерживается базовой командой разработчиков международного сообщества.  Через пользовательские группы, онлайн форумы и ресурсы разных компаний, специализирующихся на DNN, поддержка всегда близка и под рукой.

Легко устанавливаемый – DotNetNuke можно установить в течение нескольких минут. Нужно просто загрузить программное обеспечение от DotNetNuke.com и следовать за его инструкциями. В дополнение к этому много хостинг компаний помогают устанавливить dotnetnuke.

Локализованность – DotNetNuke включает многоязыковую поддержку и позволяет администраторам легко переводить свои порталы на другие языки. Так как в этом проекте задействованы разные страны, то всегда можно найти нужную версию языка для вашего сайта.

Открытость – DotNetNuke - бесплатный, открытый код и лицензируется согласно стандартному BSD соглашению. Это позволяет разработчикам создавать коммерческие и некоммерческие приложения.

Ультрасовременность - DotNetNuke предоставляет пользователям возможность изучить лучшие методы проектирования модулей, используя передовые технологии, такие как ASP.NET 2.0, Visual Web Developer (VWD), Visual Studio 2005 и SQL Server 2005 Express.

Расширяемость –  DotNetNuke в состоянии создать самые сложные системы управления контентом сайта. Он позволяет администраторам работать эффективно с добавлениями и решениями других лиц. Модули DNN и скины легко найти, купить или построить. Возможности по настройке страниц сайта - безграничны.

Признание – DotNetNuke -  торговая марка широко признана и уважаема в мировом сообществе. Более чем 400 000 зарегистрированных пользователей и талантливая команда разработчиков продолжает развивать его программное обеспечение.

DotNetNuke разработан для использования на Microsoft ASP.NET 2.0 платформы. Последний раз выпущена версия - 4.5.

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

      При установке защиты, первым делом нужно задать себе вопрос: что и от кого Вы собираетесь защищать? Дело в том, что попытки создать «непрошибаемую» защиту однозначно обречены на провал. К тому же, часто опасения по поводу желания кого либо «взломать» Вашу базу сильно преувеличены. Обычно при разработке проектов, требующих повышенного уровня надежности и безопасности применяют не Access, а другие, более подходящие для такого дела хранилища данных – например SQL Server. Для всех остальных случаев вполне подходит стандартная защита Access при помощи файла рабочих групп.

      Рабочей группой в Access называется группа пользователей, работающих с базой.

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

      Когда пользователь в первый раз запускает Microsoft Access после установки Microsoft Office, Access автоматически создает файл рабочей группы, который идентифицируется по указанными пользователем имени и названию организации. Относительное расположение файла рабочей группы записывается в следующие параметры реестра:

HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Access\Jet\4.0\Engines\SystemDB

и

HKEY_USERS\.DEFAULT\Software\Microsoft\Office\10.0\Access\Jet\4.0\Engines\SystemDB

      Можно так же посмотреть, где лежит стандартный файл рабочей группы через Сервис – Защита – Администратор рабочих групп – Связь – Обзор – тут видим System.mdw. Убедится же в том, что Access его создает при запуске (если его нет) можно очень просто -  удалите его и закройте Access. Снова откройте Access и создайте новую пустую базу. Теперь посмотрите Сервис – Защита – … System.mdw опять появился.

      То есть, по сути, стандартная система защиты Access всегда включена. До активизации пользователем процедуры подключения для рабочей группы, Access при первом запуске или при создании новой базы проверяет наличие файла рабочей группы, и если его нет, то создает его и автоматически подключает к нему всех пользователей с помощью встроенной учетной записи пользователя «Admin» с пустым паролем. Окно для ввода логина и пароля при этом не выводится, а потому создается впечатление, что база ничем «не защищена». Это верно в том смысле, что дверь не заперта, а лишь прикрыта – любой может ее открыть.

      Можно и самому создать собственный mdw. Для этого жмем Сервис – Защита – Администратор рабочих групп – Создать. Откроется диалоговое окно Сведения о владельце рабочей группы.  В поля Имя  и Организация введите название рабочей группы и если хотите, организации. В поле Код группы введите уникальный идентификатор группы, состоящий из букв и цифр. Этот идентификатор может включать до 20 символов. В качестве идентификатора защиты рекомендуется использовать набор символов, который сложнее угадать, чтобы обеспечить тем самым большую степень защищенности рабочей группы.

      Нажмите кнопку ОК. Появится диалоговое окно, позволяющее задать имя нового файла рабочей группы. Введите полное имя файла с расширением mdw, или нажмите кнопку Обзор, чтобы выбрать папку, в которой будет сохранен новый файл, и укажите имя файла. Если Вы не укажите имя файла, то Access сам его придумает – это будет конечно же System1.mdw. Нажмите кнопку ОК. Появится диалоговое окно, позволяющее проверить введенную информацию. Нажмите ОК. Созданный mdw автоматически присоединяется к Access, то есть теперь все базы на данной машине будут запускаться через него.

      Об этом часто забывают начинающие разработчики : то, что созданный ими файл рабочей группы можно подключить не только к конкретной базе, но и для всех приложений Access. Для этого достаточно указать его через Сервис – Защита – Администратор рабочих групп – Связь – Обзор – ….mdw. Теперь все базы будут открываться лишь после прохождения «авторизации» через созданный mdw, то есть каждый раз придется водить имя пользователя и пароль, хотя база может быть и не защищена. Это иногда приводит в смятение начинающих экспериментаторов: "наиграшись" с Администратором рабочих групп и своими mdw хочется вернуть все "как было", но вот как? Избавиться от этого просто: укажите стандартный mdw вышеуказанным способом (C:\Documents and Settings\Администратор\Application Data\Microsoft\Access\System.mdw). Но можно сделать проще -  передвиньте куда-нибудь созданный вами mdw – Access его «потеряет» и при запуске спросит: «Access не может найти …mdw. Использовать файл рабочей группы по умолчанию?» Скажите «Да» и создастся новый стандартный mdw с полными правами для всех пользователей и с отключенным диалоговым окном ввода логина/пароля. Но тут есть один момент: новый mdw будет уже System1.mdw – ведь старый System.mdw никуда не делся. В следующий раз при подобных действиях появится соответственно System2.mdw и т. д. Все это копии одного и того же стандартного файла рабочих групп. Чтобы не плодить их до бесконечности, подключитесь к «родителю» - System.mdw, остальные удалите.

      А вот чтобы окно авторизации выводилось лишь на конкретную защищенную базу, ее нужно запускать через специальный ярлык с параметрами командной строки. Для этого создаем ярлык базы данной, жмем на него правой кнопкой – Свойства – Вкладка Ярлык и в поле Объект пишем:

"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" "Полный путь к защищенной базе"/WRKGRP "Полный путь к файлу рабочей группы - mdw"

      Здесь происходит последовательное выполнение команд: сначала запускается СУБД Access - MSACCESS.EXE (для Office 2003 нужно Office10 заменить на Office11), затем запускается база с указанием пути к соответствующему пользовательскому файлу рабочей группы. Если первая и последняя команды пропущены, то к базе подключается mdw используемый по умолчанию.

Итак, что такое mdw, как его подключить к Access или к конкретной базе данных разобрались. Осталось теперь разобраться, как же собственно производить установку защиты через файл рабочих групп? Об этом в следующей статье.

      Начиная с версии Office 2003 появилась такая новизна: при попытке запустить приложение Office, содержащее макросы, появляется сообщение, предлагающее заблокировать «небезопасные выражения». Речь идет о возможных вирусах, содержащихся в макросах и модулях приложения.

      Microsoft предлагает такой вариант решения проблемы (из Help):

• выполняйте на компьютере современные антивирусные программы
• установите высокий уровень безопасности для макросов
• снимите флажок Доверять всем установленным надстройкам и шаблонам
• используйте цифровые подписи; поддерживайте список доверенных издателей. Чтобы изменить список надежных издателей макросов, на компьютере должен быть установлен веб-обозреватель Microsoft Internet Explorer 5.01 с пакетом обновлений SP2 или более поздней версии.

      В Office 2003 и выше применяются три уровня безопасности:

Высокий уровень

Подписанный макрос – его обработка определяется его источником и состоянием подписи.

Не подписанный макрос - макросы автоматически отключаются. Файл не открывается.

Средний уровень

Подписанный макрос – его обработка определяется его источником и состоянием подписи.

Не подписанный макрос – пользователю предлагается открыть базу данных или отменить действие. Если пользователь решит отменить действие, файл базы данных не открывается.

Низкий уровень

При низком уровне безопасности все макросы обрабатываются одинаково, вне зависимости от их происхождения или статуса сертификата. При таком уровне безопасности пользователю не предлагается оценивать надежность автора или сертификата макроса. Макросы включаются автоматически. Этот параметр следует использовать только если все макросы в файлах получены из надежных источников.

      Это было мнение Helpa. Но вот что приходит в голову, после некоторого размышления на эту тему:

1. Чтобы заработала вся эта система сертификаций, необходимо установить Microsoft Jet 4.0 Service Pack 8 или более поздней версии. В этом случае будут исполняться только макросы, имеющие специальную цифровую подпись от «надежных производителей». Многие разработчики (и не только начинающие), вряд ли когда – ни будь вздумают «подписывать» свои модули цифровыми подписями. Во первых, хакерам это вряд ли сильно помешает подделать подпись, а во вторых, услуга эта платная, и цифровой сертификат можно получить лишь в коммерческом центре сертификации, таком как VeriSign Inc., или у администратора внутренней безопасности или специалиста отдела информационных технологий (IT)
2. Если Вы создали приложение для себя, а в себе Вы уверены, что не будете создавать вирусы, то можете поставить уровень безопасности «Низкая» и спокойно работать.
3. Так же, если Вы создали дистрибутив программы, то при попытке запустить его у пользователя, который не сменил заранее уровень безопасности, появится сообщение о невозможности нормальной работы с программой. Как вариант – предложить пользователю инструкцию, объясняющую куда зайти и что переключить. Но такое решение некоторым Вашим заказчикам покажется чересчур сложным. Не все хотят вникать в такие тонкости, большинству нужно лишь, чтобы программа «нормально работала».

      Вывод напрашивается сам собой – программно переключить блокировку макросов и не морочить голову себе и Вашим клиентам. Но тут сразу возникает проблема: чтобы отключить блокировку, нужно запустить соответствующую процедуру, а запустить ее мы можем лишь после старта приложения, которое заблокировано. Тут на помощь придет VBS.

      VBS – это Microsoft Windows Script Technologies. Своеобразная альтернатива досовских .bat файлов. Сценарии написанные на VBScript и сохраненные как файлы с расширением .vbs выполняются с помощью инструмента Windows Script Host (WSH), который встроен в ядро Windows уже с 98 версии.

      Говоря проще – это обычный текстовый файл, и создается он в простом блокноте, или в его более продвинутом варианте – Bred, или кому что больше нравится. После создания файла, вручную меняем расширение на .vbs и все – получаем исполняемый файл. Щелкнем дважды по нему – компилятор Windows обработает текст и выдаст результат. Совсем как в .exe файлах. К тому же, синтаксис VBS очень похож на VB, в чем Вы сможете убедиться чуть позже, и соответственно, не составит большого труда разобраться в коде.

      Итак, рассмотрим задачи, которые надо решить:

1. Определить версию Access – ведь при установке Office 2003 путь к нужному параметру реестра (который надо изменить) будет HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Access\security\Level, а при установке Office 2007 - HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\VBAWarnings
2. Понизить уровень безопасности
3. Определить путь к MSACCESS.EXE – он собственно запускает сам Access
4. Запустить приложение

      Возьмите базу, содержащую макросы или модули и переименуйте ее в db1.mdb (или в скрипте измените имя базы на Вашу). Создайте папку например С:/Prog и поместите в нее скрипт и базу. Откройте Access и через Сервис – Макрос – Безопасность установите уровень защиты «Высокий». Попробуйте запустить приложение – появится сообщение о блокировке. Теперь запустите скрипт двойным щелчком – приложение откроется. Посмотрите, какой теперь стал уровень защиты – низкий.

Многоуровневые справочники.

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

    В предыдущей главе предлагалось вместо создания множества однотипных справочников сделать один макет справочной формы и цеплять к нему источник данных при запуске. Но можно углубиться еще дальше. Воспользуемся идеей, которую предложил Валерий Крук – сделаем одну справочную таблицу и будем хранить в ней данные всех справочников. Для этого потребуется еще одно поле – идентификатор «справочной таблицы», чтобы определить, к какому справочнику относится данная запись. А для реализации двухуровнего справочника создадим вторую таблицу, в которой будут храниться связанные с первой таблицей записи.

    При установке связей между таблицами СПРАВОЧНИК и СПРАВОЧНИК Sub установим флажок «Каскадное удаление связанных записей» - это как раз тот случай, когда такая процедура будет полезной. Ведь при удалении записи из таблицы «СПРАВОЧНИК» связанные с ней данные становятся не нужными.

    Если Вы откроете схему данных, то увидите только две связанные между собой справочные таблицы. В предыдущем примере к основной таблице «Адресат» были привязаны все справочники, и я еще подробно рассказывал о связях, флажках… Дело в том, что при данной схеме организации справочной системы мы не сможем прицепить таблицу «СПРАВОЧНИК» к какому либо полю, ведь в ней теперь хранятся все справочные данные. Да в этом и нет надобности. Если учесть, что пользователь будет работать с базой исключительно через формы, то вероятность ввода в основную таблицу записей, которых нет в справочной, сводиться практически к нулю.

    Параметры справочников хранятся в служебной таблице tSystemFormPar. В поле Tabl указан идентификатор соответствующего справочника.
Рассмотрим отличия от предыдущего варианта.

    Все глобальные переменные и константы я  перенес в специальный модуль, который так и называется Constants. Хотя объявлять их можно в любом модуле, главное, чтобы они были в разделе General и начинались с ключевого слова Public, но лучше хранить их для наглядности в одном месте.

    В модуль SprawForm добавилась новая функция – fFilListBox. Она во многом похожа на fFilForm, но служит для фильтрации списка, поэтому в параметрах вместо frm As Form поставлено lst As ListBox. Кроме этого, в  обеих функциях изменена строка формирования фильтра:

strFiltr = " WHERE Left([" & strFieldName & "]," & Len(strFiltr) & ") = '" & strFiltr & "'" & " and СПРАВОЧНИК.Type = " & strTableName

Ведь теперь нужно фильтровать не только по значению в поле фильтра, но так же и по параметру (идентификатору справочника) в таблице tSystemFormPar. Так же если для формы источник данных задается через

RecordSource = strSql1 & strFiltr & " " & strSql2

то для списка нужно использовать свойство RowSource

RowSource = strSql & strFiltr & " " & strSql1

    Добавилась функция удаления записей – sDeleteRecord. Пользовательская функция нужна для перехвата события удаления. Теперь посмотрим, что изменилось в модулях форм.

    В модуле формы «Справочник» добавилось условие отбора по полю Type таблицы СПРАВОЧНИК

Me.Subfrm.Form.RecordSource = strSql2 & " WHERE СПРАВОЧНИК.Type = " & strTableName & strSql3

и появилось новое – присвоение полю Type значения по умолчанию, равное текущему значению переменной strTableName

Me.Subfrm.Form!Type.DefaultValue = " & strTableName

    Ведь если этого не сделать, то запись в таблице СПРАВОЧНИК окажется не привязанной к текущему типу справочника.

    В модуле формы двухуровневого справочника «СправочникМ» видим, что формируются две пары строк – источников данных: strSql, strSql1 – для списка и strSql2, strSql3 – для табличной формы. Строки разбиты на пары потому, что между ними нужно будет вставлять условие отбора (WHERE…) Чтобы новое введенное значение в поле формы тут же отображалось в списке, служит процедура

Private Sub Fld_AfterUpdate()
    DoCmd.RunCommand acCmdSaveRecord
    Me.ListB.RowSource = strSql & " WHERE СПРАВОЧНИК.Type = " & strTableName & strSql1
End Sub

А для навигации по форме (поиску нужной записи) используем

Private Sub ListB_AfterUpdate()
Dim rs As Object
    Set rs = Me.Recordset.Clone
    rs.FindFirst "[id] = " & Str(Nz(Me![ListB], 0))
    If Not rs.EOF Then Me.Bookmark = rs.Bookmark
End Sub

    Чтобы исключить возможность ввода в табличную форму (источник - СПРАВОЧНИК Sub) записей, не связанных с основной формой (источник - СПРАВОЧНИК) служит процедура, которая выводит соответствующее сообщение при подобной попытке и блокирует ее:

Private Sub Subfrm_Enter()
    If flgDeleteRecord = False Then
        If IsNull([id]) Then
            MsgBox "Сначала нужно завести основные данные!", vbCritical, NomWers
            Fld.SetFocus
        End If
    End If
End Sub

    Раз на форме появилось второе поле фильтра, появилась соответствующая процедура фильтрации по этому полю

Private Sub П2_Change()
    strFiltr = Me.П2.Text
    Set idField = Me.П2
    Call fFilForm(strFiltr, strSql2, strSql3, Me.Subfrm.Form, "Name")
End Sub

    Подобный вариант организации справочной системы – с использованием общих таблиц для разных справочников, позволяет не только значительно упрощать создание справочников (для этого достаточно заполнить соответствующим образом таблицу tSystemFormPar), но так же уменьшает размер базы за счет меньшего количества форм и таблиц.

А теперь можете поэкспериментировать, создавая разного вида справочники  - простые и двухуровневые.

Шифрование/Дешифрование базы средствами Access.

    Вот что я нашел про кодирование/раскодирование баз данных Access в книге «Access 2002. Разработка корпоративных приложений.» П.Литвина, К.Гетца и М.Гунделоя.

    «Как бы хорошо не была защищена база данных Jet, любой мало-мальски сообразительный хакер может при помощи низкоуровневого дискового редактора и получить доступ к её содержимому. Поэтому серьезная защита баз данных предполагает ещё и их шифрование. Конечно, взлом баз данных – дело не самое обыденное, но искатель приключений всегда может найтись. Само по себе шифрование базы данных ещё не гарантирует её надежной защиты, но всё же препятствует её просмотру средствами, внешними по отношению к Access и Jet.

    Зашифровать и дешифровать базу данных могут только её владелец и члены группы Admins. Для шифрования Jet использует алгоритм RSA (назван по первым буквам фамилий его изобретателей: Rivest, Shamir, Adelman) с ключом на основе идентификатора рабочей группы. Для шифрования и дешифрования предназначена команда Access Tools > Security .> Encrypt / Decrypt Database.

    У шифрования базы данных имеется два негативных побочных эффекта. Во-первых, снижается её быстродействие – по оценкам Microsoft, процентов на 10-15. Во-вторых, зашифрованную базу данных нельзя сжимать такими программами, как PKZip, LHA, Stacker и DriveSpace. Точнее, сжимать можно, только в этом нет смысла – её размер уменьшится незначительно».

    Вот, что удалось ещё нарыть на сайте Microsoft:

    Шифрование базы данных — это простейший способ защиты. При шифровании базы данных ее файл сжимается и становится недоступным для чтения с помощью служебных программ или текстовых редакторов.

    Шифрование незащищенной базы данных неэффективно, поскольку каждый сможет открыть такую базу данных и получить полный доступ ко всем ее объектам.

    Шифрование обычно применяется при электронной передаче базы данных или сохранении ее на дискету, кассету или компакт-диск. Шифровать-расшифровывать базу может либо хозяин базы, либо пользователь с администраторскими привилегиями и разрешением загружать базу в монопольном режиме.

    Немного потыкал клавиши. В шифрованную базу можно добавлять записи, а имеющиеся - изменять. Шифрованную базу можно сжимать. Таблицы из шифрованной базы можно подлинковывать.

    Пароль на базу не шифруется. Тело базы шифруется начиная с адреса 1000h. При просмотре тела базы разными вьюерами там действительно ерунда. Программы типа AccessFix не могут ничего из базы выдрать. (по крайней мере версии 3.70). Они там просто ничего не находят. Объекты из шифрованной базы можно импортировать в другую базу и они уже будут не шифрованные.

    Вывод, шифровать стоит базу, уже защищенную стандартными средствами при помощи MDW.

    На что не смог найти ответа:

1. можно ли к шифрованной базе подключиться из других клиентов - VB, Delphi, VC... (скорее всего можно)?
2. в случае краха, какова вероятность восстановления шифрованной БД?

Об алгоритме шифрования RSA можно прочитать вот здесь http://ru.wikipedia.org/wiki/RSA
А об его стойкости - http://www.bugtraq.ru/library/crypto/rsa.html

    В то время, когда составлялась данная рассылка, Валерий Крук опять удивил общественность, предложив очень интересную идею. Вкратце суть его предложения в следующем:
Часто бывает, что вариантов для подстановок значений в поле формы не много и поэтому заводить для этого отдельную таблицу - справочник не желательно. Вставлять же заранее все значения в поле со списком тоже не выход, ведь иногда приходится менять содержимое списка. Валерий же предлагает компромисс – объединить справочные данные для нескольких списков в одну таблицу. А заодно предложил оригинальный интерфейс для ввода/редактирования данных.
Подробно рассказывать я не буду, иначе получится плагиат, желающие могут ознакомится с примером по ссылке http://am.rusimport.ru/MSAccess/topic.aspx?id=598

    В предыдущей статье рассматривался пример добавления отсутствующего значения в список подстановок. Но данные не сохранялись, потому что для этого нужна справочная таблица. Теперь я покажу аналогичный пример, но уже с использованием справочной таблицы, тем самым решится проблема сохранения нового значения в справочнике. Добавлять данные, так же как и в предыдущем примере будем программно. Для этого воспользуемся DAO - Data Access Objects - объектная модель доступа к данным. Объекты доступа к данным создавались, как объектно - ориентированный интерфейс для ядра баз данных Jet фирмы Microsoft как раз для того, чтобы можно было программно вносить, изменять, удалять данные в таблицах.
    Создадим функцию AppendLookupTable и поместим в общий модуль, чтобы ее можно было вызывать из разных форм, для разных полей со списками, а не только для конкретного.

    Для работы с таблицей программно (через DAO), сначала необходимо объявить объектную переменную и присвоить ей источник данных (Recordset):

Dim rst As DAO.Recordset     ‘ объявляем переменую
Set rst = CurrentDb.OpenRecordset(ПолеСоСписком.RowSource) ‘ ТекущаяБаза.ОткрытьИсточникСтрок(ПолеСоСписком.ИсточникСтолбцов)

а далее стандартная обработка Recordset

rst.AddNew     ‘ ДобавитьНовуюЗапись
rst(i) = NewData         ‘ НовыеДанные
rst.Update        ‘ скорректировать (обновить источник)
rst.Close          ‘ закрыть источник

    при работе с таблицей/запросом через DAO после выполнения действий со строками обязательно должно быть обновление источника rst.Update. Иначе компилятор тут же выдаст ошибку. И не забываем закрывать источник после работы  - освобождаем память. В принципе это не обязательно, при выходе из процедуры Access его все равно обнулит, но стоит выработать такую хорошую привычку – освобождать переменные в конце процедур.

    Вызывать функцию будем аналогично предыдущему примеру:

Private Sub Город_NotInList(NewData As String, Response As Integer)
Dim ctl As Control    ' Возвращает объект Control, указывающий на поле со списком
    Set ctl = Me!Город    ' назначаем переменной ctl текущий контрол (поле со списком)
' Приглашение подтвердить ввод нового значения
    Response = AppendLookupTable(ctl, ctl.Text)
    Me.Город.RowSource = Me.Город.RowSource     ' обновление списка (ведь там появился новый элемент)
End Sub

    Полный текст функции приведен в Пример1. Вариант3.

Формы – справочники.

    Теперь займемся наконец формами. Начнем с простого: создадим табличную форму – справочник. На событие «Открытие» формы вешаем процедуру:

Private Sub Form_Open(Cancel As Integer)
    Form.Caption = Me.Form.Name     ' присваиваем названию формы ее имя в базе
    DoCmd.MoveSize , , 5000, 3000   ' задаем размеры формы (ширина, высота)
    DoCmd.GoToRecord , , acNewRec   ' устанавливаем фокус на последнюю запись
End Sub

    Мы получили простейшую форму справочник. Осталось придумать, как же ее вызывать? Обычно применяют два способа:

1. Раз справочник  - источник поля со списком, то почему бы дважды не щелкнуть по соответствующему списку для его открытия? А чтобы это как то узаконить, покрасим список в синий (можно, разумеется, и в любой другой) цвет и объявим в справке к программе, что при двойном щелчке по полю синего цвета открывается подобающая ему справочная таблица. Создаем процедуру открытия табличной формы:

Private Sub idРегион_DblClick(Cancel As Integer)
    DoCmd.OpenForm "Справочник регионы", acFormDS, , , , acWindowNormal
End Sub

    acFormDS – указание на то, что форма открывается в режиме таблицы
    acWindowNormal – указываем тип границы (вид формы) – обычная Windows («Нормальная» в конструкторе форм)

    Осталось сделать еще одну важную вещь: обновить список при закрытии справочника. Ведь если мы внесли туда новые данные (или удалили) изменения желательно тут же отобразить в списке.

Private Sub Form_Close()
    If IsLoaded("Пример1") Then Forms!Пример1.idРегион.Requery          ' обновляем поле со списком idРегион на форме Пример1
End Sub

    IsLoaded – эта функция проверки, открыта ли форма "Пример1". Взята из базы «Боррей».

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

    Для организации подобного интерфейса нам понадобится служебная таблица «ФормыПараметры» и функция fOpenForm. В этом примере для разнообразия применим другой вид формы.

    Справочник у нас будет состоять из двух форм: простая форма будет служить контейнером для табличной. Поле серого цвета – поле фильтра. Начните вводить в него первые буквы искомого обозначения – и содержимое таблицы станет динамически фильтроваться (по первым буквам). Фильтрация происходит при помощи функции «fFilForm».

    А теперь самое интересное: я сделал только одну подобную форму справочник (основная форма «Справочник», починенная табличная «SubFrm»),  а в списке их у меня две: Страны, Регионы. И в базе вы не найдете форм «Справочник страны», «Справочник регионы». Откуда же они берутся? Все очень просто. Рассмотрим функцию «fOpenForm».

Function fOpenForm(КодФормы As String) As Boolean
On Error GoTo Err_
    strFormName = DLookup("ИмяФормы", "ФормыПараметры", КодФормы)
    strTextFormName = DLookup("ОбозначениеФормы", "ФормыПараметры", КодФормы)
    strTableName = DLookup("Таблица", "ФормыПараметры", КодФормы)
    DoCmd.OpenForm strFormName
    fOpenForm = True
Exit_:
    Exit Function
Err_:
    MsgBox Err.Description
    Err.Clear
    fOpenForm = False
    Resume Exit_
End Function

    Здесь мы видим процедуру присвоения значений трем переменным: strFormName, strTextFormName, strTableName. А теперь посмотрим на самый верх модуля «Module1». Там мы увидим

Public strFormName As String
Public strTextFormName As String
Public strTableName As String

    Здесь мы подошли к такому важному понятию, как область видимости переменных. Раз эти три переменных объявлены в разделе General общего модуля с ключевым словом Public, то они становятся видимыми для всех модулей приложения. Например, их "увидят" процедуры модуля формы «Справочник» для того чтобы присвоить форме соответсвующие параметры. Рассмотрим их.

    В таблице «ФормыПараметры» есть три поля: ИмяФормы (имя формы в приложении), ОбозначениеФормы (текстовое обозначение формы, или просто заголовок формы), Таблица (источник данных формы – имя таблицы). В функции «fOpenForm» происходит присвоение этим переменным значений при помощи

DLookup("ИмяПоляТаблицы/запроса", "ИмяТаблицы/запроса", "Условие отбора")

    как видно, значения берутся из полей служебной таблицы «ФормыПараметры». А затем команда на открытие формы DoCmd.OpenForm strFormName

    Теперь заглянем в модуль формы «Справочник». Рассмотрим процедуру, происходящую при открытии формы:

Private Sub Form_Open(Cancel As Integer)
    Form.Caption = strTextFormName
    Set idField = Me.П1
    strSql = "SELECT [" & strTableName & "].id, [" & strTableName & "].Обозначение FROM [" & strTableName & "]"
    strSql1 = " ORDER BY [" & strTableName & "].Обозначение"
    Subfrm.Form.RecordSource = strSql & strSql1
End Sub

    Открытие формы происходит после присвоения значения глобальным переменным. Свое обозначение и источник данных форма получает при открытии.

    В результате получился макет формы. При запуске форме присваивается текстовое обозначение и цепляется источник строк при помощи глобальных переменных, значения для которых берутся из служебной таблицы. Таким образом, становится возможным используя всего один макет формы «создавать» множество однотипных справочников. Для этого достаточно лишь заполнить необходимыми данными служебную таблицу. Единственное условие: во всех справочных таблицах должно быть два поля, называться они должны одинаково: id, Обозначение. Это накладывает ограничение на возможные варианты справочников, но ведь речь идет о простых справочных формах.

    А теперь, попробуйте сами: "создайте" справочник «Города», заполнив соответствующими данными таблицу «ФормыПараметры».

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

    Обычно справочные таблицы служат источниками данных для списков или полей со списками. Но прежде чем перейти к созданию форм – справочников, рассмотрим сначала варианты организации этих списков без использования справочных таблиц (см. форму Пример1).

Ссылка таблицы на саму себя (Пример1. Вариант1)

    Это самый простой способ организации справочника. Создаем форму «Адресат», цепляем к ней источник – таблицу «Адресат». Создаем поле со списком, источник которого – запрос к полю «Улица» из этой же таблицы. Запрос обязательно должен быть сгруппирован и в условии отбора необходимо исключить пустые стоки (Адресат.Улица = Is Not Null). Для обновления списка можно на свойство формы «После обновления» повесить Улица.Requery. Свойство «Ограничиться списком» должно быть «Нет». Иначе нельзя будет добавлять новые данные.

    Достоинства: простота реализации, не нужны справочные таблицы, весь программный код – одной строчкой.

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

    Впрочем, пробелы можно победить например так:

    Trim([Улица])

    а за неправильность ввода бить по рукам. К тому же, если в список заводятся например номера домов в виде чисел, то этот способ в принципе заслуживает внимания. Чтобы отличить число от текста можно воспользоваться например такой процедурой:

If Val(Дом) = 0 Then
    MsgBox "Не правильный формат данных!", vbCritical, "администратор"
    Дом = Null
End If

    Но в нашем примере я завел для номеров домов тип поля «Текст» - ведь номер может быть например 1/2 или кор. 3. Поэтому, с  домами разберемся по другому.

Добавление отсутствующего значение в список значений (Пример1. Вариант2)

    Для реализации этого способа мы используем в качестве источника данных списка – «Список значений». Основа этого способа – перехват события списка «Отсутствие в списке». Вот пример процедуры:

Private Sub Дом_NotInList(NewData As String, Response As Integer)
Dim ctl As Control    ' Возвращает объект Control, указывающий на поле со списком
    Set ctl = Me!Дом  ' Приглашение подтвердить ввод нового значения
    If MsgBox("Значение отсутствует в списке. Добавить?", vbOKCancel) = vbOK Then
    ' Значение аргумента "Response" определяет добавление в список
        Response = acDataErrAdded
    ' Добавляет значение аргумента "NewData" в источник строк
        ctl.RowSource = ctl.RowSource & ";" & NewData
    Else
    ' При нажатии кнопки "Отмена" подавляет вывод
    ' сообщения об ошибке и отменяет изменения
        Response = acDataErrContinue
        ctl.Undo
    End If
End Sub

    Испытаем процедуру: раскроем сначала список, посмотрим какие там номера и введем такой, которого там нет. При переходе на новую запись или другой элемент формы появится сообщение с предложением завести новое значение списка. Скажем «Да» - значение заведется, скажем нет – сотрется.

    Достоинства: не нужны справочные таблицы.

    Недостатки: новые данные в списке, увы, не сохраняются. То есть, если в список добавилось новое значение, то при закрытии формы оно исчезнет. Все потому, что список значений можно заполнять только в конструкторе форм (в примере список не заполняется, а просто контролу временно "подсовывается" новый источник строк). Однако такой способ может оказаться полезным, когда именно это и требуется: например в списке присутствуют стандартные значения, но требуется ввести не стандартное, причем не один раз, и чтобы все разы одинаково, а в справочную таблицу заносить новые данные по каким либо причинам не следует. Ситуация довольно странная, но при работе с базами данных случается и не такое.

    В обоих примерах есть общий недостаток: сложно будет реализовать обновление однотипных данных в таблице «Адресат»  - ведь обновлять то их собственно не с чем, нет соответствующей справочной таблицы. То есть, если, например Вы решите изменить название «Москва» на «г. Москва», то придется программно отлавливать в таблице все соответствующие записи и менять их. А вот в случае с использованием справочных таблиц для этого достаточно изменить данные в справочнике. О различных вариантах оформления форм – справочников я расскажу в следующей статье.

    В каждой базе данных есть справочники, которые служат для хранения часто вводимых данных.  Например, если в таблице «Атрибуты заказчика» есть поля типа «Страна», «Город», то вместо того, чтобы постоянно вводить вручную эти данные, можно завести соответствующие справочники и подставлять данные из них. Но дело в том, что справочники могут быть как простые, состоящие из одной таблицы, так и сложные, составные (многоуровневые). В этом цикле статей мы рассмотрим примеры организации различного рода справочников.

    Идею статьи подсказало следующее сообщение на http://am.rusimport.ru/MSAccess/f2.aspx?type=1&id=42149

    Подскажите, как правильно разработать структуру базы для реализации почтовой базы. Интересует правильная связь таблиц: Страна, Регион, Город, Улица.

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

    Создаем четыре таблицы: Адресат, Справочник страны, Справочник регионы, Справочник  города. В каждой таблице обязательно должно быть соответствующее ей ключевое поле (Тип Счетчик) – idАдресат, idСтрана, idРегион, idГород. Назвать их разумеется можно и по другому.

    Обычно ключевое поле таблицы, которое является уникальным идентификатором записи в этой таблице, называют внутренним ключом (в нашем случае это поля типа «Счетчик»), а ключевые поля,  через которые внешние таблицы привязаны к данной – соответственно внешними ключами (в нашем случае это числовые поля Длинное целое)

    В руководствах для начинающих разработчиков часто присутствуют рассуждения, какое поле сделать ключевым. Дается определение ключевых полей и приводятся примеры связей между ними. На мой взгляд, такие рассуждения только сбивают с толку начинающих. Ведь в принципе, все довольно просто: в 99% случаев лучшее ключевое поле – счетчик. Оно 100% уникально (без повторений) и при установке связи с основной таблицей (в которую подставляются данные из этого справочника) с соответствующим полем Числовое (Длинное целое) связь автоматически определяется как один ко многим (одна запись в справочнике и много аналогичных записей в основной таблице).

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

    Как видно, в справочниках только два поля: ключевое и обозначение. А основная таблица состоит в основном из числовых полей, кроме поля «Улица». Вот здесь то и проявляется основная особенность построения реляционных баз данных:

    вместо того, чтобы хранить в таблице «Адресат» наименования стран, регионов, городов в виде текста, сохраним их лучше в виде чисел (значений ключевых полей справочников).

При установке связей между основной таблицей и справочной Access обнаружив ключевое поле в основной таблице, пойдет по установленной связи в справочную и считает оттуда соответствующее значение из поля таблицы. Из какого поля – это будет зависеть от запроса, который мы создадим далее.

    Справочники «Улицы» и «Дома» создавать, как мне думается, нет смысла. Улиц будет слишком много, их проще ввести вручную.
Так же в справочных таблицах не помешает сделать поле «Обозначение» уникальным, не допускающим повторений. Для этого в конструкторе таблицы в свойстве поля «Индексированное поле» выберем «Да. Повторения не допускаются». Если теперь нажать в конструкторе таблиц на кнопку «Индексы» (на ней значок молнии), то увидим, что в таблицу кроме основного индекса ключевого поля добавился еще один – «Обозначение».

    Имена полей таблиц не должны содержать пробелов, иначе могут быть проблемы с VBA, и однозначно возникнут проблемы, при переносе базы на SQL Server. Если имя поля состоит из двух слов, то можно выбрать например такай вариант: НазваниеУлицы или Название_улицы.

    Хотя согласно Help, имя может включать любую комбинацию букв, цифр, и специальных знаков за исключением точки (.), восклицательного знака (!), надстрочного знака (`) и квадратных скобок ([ ]), но  желательно не использовать в именах полей таблицы никаких символов, кроме букв и цифр. Дело в том, что например имя поля таблицы типа «Улица№» в проекте mdb скорей всего не вызовет никаких конфликтов, а вот при переносе базы на SQL Server, мастер переноса просто «выкинет» его из таблицы.

    При создании однотипных таблиц дело пойдет быстрее, если в окне проекта «Таблицы» выделить таблицу, затем Ctrl + C или в контекстном меню при правом щелчке мыши выбрать «копировать», затем выбираем вставить, в появившемся окне задаем имя новой таблицы и жмем «ОК». Осталось только в ключевом поле «id…» изменить обозначение (было к примеру «idГород», а теперь сделаем «idРегион»). Остальное менять не нужно. Вот потому то я во всех справочниках ввел однотипное поле «Обозначение». В таблице «Адресат» так же создаем внешние ключевые поля (Длинное Целое) - idСтрана, idРегион, idГород. Не забудьте убрать в них значение по умолчанию = 0.

    Теперь осталось только установить связи между таблицами. Жмем в окне проекта на кнопку «Схема данных» или правой кнопкой мыши, и в контекстном меню выбираем «Схема данных». Появилась диалоговое окно «Добавление таблицы». Щелкаем дважды по всем названиям таблиц и закрываем окно.

    Располагаем таблицы например так:  слева основная – «Адресат», справа остальные. Наводим курсор в таблице «Адресат» на поле «idСтрана» нажимаем и тащим на поле «idСтрана» в таблице «Справочник страны». В появившемся диалоговом окне «Изменение связей» устанавливаем флажки: «Обеспечение целостности данных», «Каскадное обновление связанных полей» и жмем «ОК».

Флажок «Обеспечение целостности данных»

    Его установили для того, чтобы исключить возможность ввода в таблицу «Адресат» в поле «idСтрана» значения, которого нет в аналогичном поле справочной таблицы «Справочник страны». Советую всегда так делать. Этим Вы во многом избавитесь от проблемы «мусора» в базе данных – наличие ни с чем не связанных записей. Правда есть и другие способы «замусоривания», но не лишним будет уже в структурной схеме базы постараться свести их к минимуму.

Флажок «Каскадное обновление связанных полей»

    В данном случае можно было бы и не ставить. Дело в том, что ситуация, когда нужно обновлять связанные поля, здесь вряд ли произойдет, ведь ключевое поле в справочной таблице изменить можно только программно. Тем не менее, в нашем случае хуже от этого не будет.

    А вот флажок «Каскадное удаление связанных записей» в данном примере я бы не рекомендовал ставить. Иначе может возникнуть весьма печальная ситуация: пользователь решит удалить название города из соответствующего справочника (мол, больше не нужен), а вместе с ним удалятся и все связанные с ним записи в таблице «Адресат» - это и есть каскадное удаление. Правда, при всякой попытке удаления Access выдает соответствующее предупреждение, но надеяться на то, что пользователь адекватно среагирует на него, я бы не стал. Каскадное удаление имеет смысл ставить в случае, например при связи таблиц «Заказы» и «Заказы данные». Удаляете заказ, а вместе с ним автоматически и все данные по нему, так как зачем данные по заказу, которого больше нет.

    Остановлюсь еще на одном моменте: многим наверное приходилось сталкиваться с ошибкой «Слишком большое число». Если не хотите иметь с этим проблем, возьмите себе за правило не делать поля со списками в таблице (начинающие обычно для этого используют мастер подстановок). Дело в том, что из за несоответствия форматов единиц измерения ширины столбцов в разных версиях Access, эта самая ширина может вместо стандартной 2,54см  стать … 57,2 см (слишком большим). Поэтому список лучше сделать на форме, а в таблице оставьте просто поле.
В следующем выпуске я расскажу о вариантах реализации справочной системы без использования справочных таблиц