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

Мои доводы ЗА:
1. Модульность. Временные таблицы позволяют разделить между собой отчет и код расчета данных. В последующем это повышает сопровождаемость (см. п.3).

2. Удобство отладки. Если отчет перестал работать или работает как-то не правильно, то гораздо легче проверить расчет данных для него.

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

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

Мои доводы ПРОТИВ:
1. Увеличивается время разработки. Это происходит в том случае, если для отчета можно использовать простой запрос в качестве источника данных. Если же расчет данных не вписывается в простейшие запросы, то будет проще и надежней реализовать расчет отчета в коде.

Больше против я не вспомнил. Выбор очевиден . Увлекаться данным способом естественно не стоит, каждой проблеме лучше подбирать свое решение. Этот метод подходит для отчетов со «сложными» расчетами данных.

До встречи!

(с) Скоков Сергей

Подписаться на: RSS или e-mail рассылку или добавить в ЖЖ друзья.

Поговорим в этом выпуске об очень интересной штуке — события. Я очень мало где видел их использование в MS Access. Но они очень сильно облегчают жизнь при работе, особенно с формами. У событий есть маленькое ограничение. Их могут использовать только объекты. Это означает, что их можно объявлять и получать только в модулях пользовательских классов, формах и отчетах.

Чтобы объявить событие необходимо в начале модуля класса (формы, отчета или пользовательского) написать:
Event ИмяСобытия( СписокАргументов )

Для использовании события необходимо объявить в начале модуля ссылку на объект и в списке (левый список, который расположен в редакторе кода) выбрать обявленный атрибут, в правом списке можно выбрать событие, если их несколько. В результате получим следующее:
Dim WithEvents Имя As Тип

Вызвать событие можно так:
RaiseEvent ИмяСобытия( Параметры )

Где это можно применить? Рассмотрим пример из жизни. На форме заказа есть поле клиента. В этом поле отображается, допустим, УНН и название клиента. Рядом с полем кнопка. По нажатию на кнопке отображается еще одна форма — список клиентов. Задача — выбрать клиента.

Одним из решений будет открыть модальное окно и тут возникает куча разных вариантов: записать напрямую с формы списка клиентов в поле формы заказов (очень плохая идея!!!), скрыть форму при нажатии пользователем кнопки «Ок» (Выбрать) и т.д.

При помощи событий получается простое и элегантное решение. Всего-то объявить на форме списка клиентов событие:
Event OnClientSelect(ByVal lId As Long)

На форме заказа это событие обработать:

Dim WithEvents m_frmKlientSepis As Form_frmKlientSpis
'--

Private Sub Kn_KlientSelect_Click()
	'-- выбор клиента
	'-- можно и так
	'-- DoCmd.OpenForm "frmKlientSpis"
	'-- Set m_frmKlientSepis = Forms("frmKlientSpis")

	'-- но мне нравится этот вариант
	Set m_frmKlientSepis = New Form_frmKlientSpis
	m_frmKlientSepis.Visible = True
End Sub

Private Sub m_frmKlientSepis_OnClientSelect(ByVal lK_KLIENT As Long)
	'-- клиент выбран пользователем
	Me.K_KLIENT = lK_KLIENT
	Set m_frmKlientSepis = Nothing '-- уничтожаем форму
End Sub

Подробности можете увидеть в примере. Чуть позже я расмотрю еще один пример — связные списки.

До скорых встреч!

(с) Скоков Сергей

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

MS Access представляет из себя конструктор со встроенным языком программирования. Формы, отчеты, запросы и пр. никакого отношения к языку не имеют. Можно сказать, что они представляют из себя хранимые настройки классов Form, Report, QureyDef и п.р. При создании формы не обязательно создается модуль класса (далее класс), только если указать в свойстве «наличие модуля» да или создать обработчик события. В этом случае имя класса будет Form_<имя формы>. Это истинно и для отчетов.

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

Обращение к элементам управления формы
Для начала рассмотрим взаимодействие с элементами управления на форме. Далее под словом поле буду понимать элемент управления. К полям на форме в модуле формы (он же модуль класса) можно обращаться следующими способами:
1. Me![<имя поля>]
2. Me(«<имя поля>»)
3. Me.Controls(«<имя поля>»)
4. Me.<имя поля>
5. <имя поля>

Вопрос, какой из методов компилируем? Правильный ответ 4 и 5 (действителен только в пределах модуля формы), все остальные варианты содержат текстовую константу с именем поля. Теперь рассмотрим, как это работает. Мы создали форму, разместили на ней поля. Прошло некоторое время. Какие-то поля мы удалили, у каких-то изменили имя. Задача состоит в том, чтобы проверить код на этой форме, чтобы нигде не было ошибок. Можно это сделать «глазками». А можно открыть редактор кода, выбрать пункт Debug->Compile. По ошибкам можно быстро найти места с багами. Если мы будем использовать любой способ, кроме 4-го, то это нам не поможет. Придется убеждаться в правильности методом испытания формы в реальном бою – то есть проводить тестирование. Поверьте, скомпилировать дешевле по времени.

Взаимодействие с полем формы
Усложним задачу – обратимся к полю извне формы. Перед этим рассмотрим варианты обращения к открытой форме:
1. Forms(«<имя формы>»)
2. Forms![<имя формы>]

Как видите эти методы не очень то и сопровождаемы, так как ссылку на открытую форму можно получить только по имени (Если форма открыта методом DoCmd.OpenForm). Можно постараться оптимизировать:

Dim frm as Form  

DoCmd.OpenForm "f_doc"
'-- тут такие параноики как я могут проверить, отрылась ли форма
Set frm = Forms("f_doc")
frm. <имя поля> = 123

Вместо абстрактной формы <имя формы> появилась форма f_doc. Она же и будет использоваться далее.

И в этом случае поле будет определяться компилятором на этапе выполнения. Потому что класс Form не содержит этого поля. Чтобы это произошло на этапе компиляции необходимо по другому определить переменную frm:

Dim frm as Form_f_doc  

DoCmd.OpenForm "f_doc"
Set frm = Forms("f_doc")
frm. <имя поля> = 123

В результате компилятор знает тип формы, во время редактирования подскажет вам какие поля и методы пользователя есть на форме. Если мы решим изменить имя поля или метода, то скомпилировав, по ошибкам можно будет все найти и исправить.

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

Открытие формы
Открытие формы на кнопку очень просто сделать при помощи мастера. Одинаковые кнопки на разных формах можно очень быстро наплодить. Но если мы хотим сэкономить в будущем, то придется немножко пописать руками.
Открытие формы при помощи DoCmd.OpenForm не совсем надежно, т.к. имя формы не проверяется компилятором. Только во время выполнения получим сообщения об ошибке.
Как можно свести ошибки в имени формы к минимуму? Константы!

Const c_imFrmDoc as String = "f_doc"

Теперь код превратиться в:

Dim frm as Form_f_doc  

DoCmd.OpenForm c_imFrmDoc
Set frm = Forms(c_imFrmDoc)
frm. <имя поля> = 123

Это еще не все. Если подобным образом нужно каждый раз открывать форму, то эти 4-е строчки кода придется дублировать каждый раз при открытии этой формы. Я очень популярные формы открываю при помощи специальных функций. Это гораздо удобнее, чем использование только констант. Например:

Fumction OpenFrmDoc() as Form_f_doc
On Error GoTo Err_
	DoCmd.OpenForm c_imFrmDoc
	Set OpenFrmDoc = Forms(c_imFrmDoc)
Exit_:
	Exit Function
Err_:
	Resume Exit_
End Function

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

Как еще можно открыть форму? Можно еще и так:

Dim frm as Form_f_doc  

Set frm = New Form_f_doc
'-- взаимодействие с формой

Стоит обратить внимание на 3 строчку. В ней создается новый объект указанного класса. Бонус этого метода в том, что позволяет наплодить множество экземпляров одной и той же формы. Но не позволит запустить форму в диалоговом режиме и не добавит ее в коллекцию Forms. Т.е. ссылку на форму необходимо сохранить в переменную и до тех пор пока будет хоть одна ссылка на это форму, она будет существовать.

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

(с) Скоков Сергей