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

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

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 5.413 RSS
←   Июль 2012   →
 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.413 подписчиков
0 за неделю
←   Все выпуски   →

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


Выпуск 9. Access Rapid Start - конструктор приложений в Access

Подписка: "Access 2003/2010 - программирование и готовые решения"
Дата: 02.07.2012
Автор: Парусников Алексей
Сайт: http://www.accessoft.ru под редакцией с http://www.leadersoft.ru
Загрузка: ARS 2003 ARS 2007 ARS 2010
Получить ключ: Key_ARS

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

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

     В системе ARS используется интерфейс поиска/редактирования данных, включающий в себя пару форм: поисковая и редактор. И мы настоятельно рекомендуем в ваших разработках придерживаться именно такого стиля. Не нужно пытаться вывести все в одну форму: ввод, редактирование, поиск. Это устраивает, когда нет задачи разделения прав доступа и пока поиск самый примитивный: стандартная форма поиска Access или поле-фильтр со списком подстановок. Поверьте нашему опыту (а заодно посмотрите, как сделано в других профессиональных программах, как организован интерфейс приложений Windows) – лучше разделить задачи поиска и ввода/редактирования, сделав их в разных формах. Тогда можно организовать мощную поисковую систему, не затрагивая функционала формы-редактора. Об интерфейсе последних мы обстоятельно поговорим в одной из следующих статей (там к сожалению тоже встречается множество безумств и нелепостей), а сейчас займемся поисковыми.

     Думаю, сделав с десяток однотипных форм-справочников, вы неизбежно придете к мысли: а что если сделать одну форму, и просто менять у нее источник? В самом деле – если структура таблиц-источников одинакова, почему бы и нет. Мы пошли еще дальше: сделали параметрическую форму, которая подключая к себе источник (таблицу или редактируемый запрос) с разным количеством полей и самонастраивается таким образом, чтобы показать все поля источника. Более того, прикрутили к ней навороченный поиск, многоуровневую сортировку, сохраненные фильтры, выгрузку содержимого в различных форматах (о впечатляющих возможностях поисковых ARS я расскажу в другой статье) и форму-редактор, которая тоже параметрическая. В итоге получается, что для создания простого справочника вам остается только зарегистрировать его источник в форме администрирования и создать пункт меню. Форму поиска и редактор делать не надо.

     В качестве примера я сделал перенос проекта Медиа-каталога, в котором удалось таким образом создать 22 справочника (из всех 25 таблиц) – тем самым оказались не нужными 22 поисковых и 22 редактора, что существенно упростило поддержку проекта (6 форм редактировать вместо 50). Однако при этом пришлось немного изменить структуру таблиц. Остановимся на этом моменте подробнее.

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

  1. Sost – флаг актуальности записи. Логическое
  2. RecAdd – дата и время создания записи. Дата/время
  3. RecEdit – дата и время изменения записи. Дата/время
  4. Oprt_ID – логин пользователя, сделавшего последние изменения. Числовое, длинное целое

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

     Например, вы сделали таблицу tab_Org, которая служит источником данных для справочников «Поставщики» и «Подразделения». В таблице есть поле OrgName, которое в первом случае используется как обозначение фирмы поставщика, а во втором как обозначение подразделения вашей фирмы. Отделять одно от другого можно при помощи флажка flg_Post. Стоит флажок – значит это запись о поставщике, не стоит – о своем подразделении (или наоборот, тут по вкусу). Затем вы делаете два запроса-источника для ваших справочников, выбирая из них все поля таблицы tab_Org, и ставите фильтр по полю flg_Post (0 в одном запросе и -1 в другом). Так вы разделили одну таблицу на две части. Назвали запросы например qry_Post и qry_MyPod, зарегистрировали их в форме администрирования, сделали два пункта меню, но… в обоих справочниках показывается например «Обозначение поставщика» - такой вы сделали подпись поля в таблице tab_Org. В этом случае и выручит алиас запроса – подпишите поле OrgName в запросе qry_Post например «Подразделения», и тогда в каждом справочнике его подпись будет показываться по разному: «Обозначение поставщика» в одном справочнике, и «Подразделения» в другом.

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

  • Убедиться, что источник данных имеет правильную структуру
  • Создать источник данных справочника (таблицу или запрос)
  • Зарегистрировать его в форме администрирования и назначить права доступа
  • Создать пункт меню в основном меню программы
     Более сложным будет создание двух-уровневого справочника, о котором я расскажу в следующей статье. Однако и в этом случае ничего программировать и тем более делать какие то формы не нужно – все по прежнему решается настройками ARS.

Полезные ссылки

Интернет магазин от Leadersoft.ru
В этом магазине Вы можете купить не только готовое программное обеспечение для бизнеса, а также найти компактные решения для самостоятельного проектирования на Microsoft Access, SQL Server или ASP.NET
В избранное