5 строк кода

Как писать приложения на MS Access

Archive for the ‘архитектура’ Category

Недостатки DoCmd.GoToRecord и достоинства CodeContextObject

Комментариев нет

Пара камней в огород DoCmd
Как-то мне понадобилось перейти к последней записи в подчиненной форме. Перейти к последней записи можно разными способами, простейший — это вот эта команда: DoCmd.GoToRecord , , acLast. Вот с подчиненненными формами есть нюанс — нужно вызывать ее в обработчике события или методе подчиненной формы. В моем случае события не подходили, метод было реализовывать влом и очень хотелось реализовать это на главной форме.

Поэтому пришлось написать свою функцию. Благодаря тому, что функция принимает ссылку на форму, а не имя, то можно ее использовать для любой формы, подчиненной, созданной при помощи DoCmd.OpenForm или оператора New.

Public Sub CM_FormGoToLastRecord(Optional ByRef frm As Form = Nothing)
' перейти на последнюю запись
' frm можно не передавать, в этом случае она будет получена при помощи CodeContextObject
On Error GoTo Err_
    
    If frm Is Nothing Then
        Set frm = CodeContextObject
    End If
    
    If frm Is Nothing Then Exit Sub
    
    Dim rst As DAO.Recordset
    
    Set rst = frm.RecordsetClone
    If Not rst.EOF Then rst.MoveLast
    frm.Bookmark = rst.Bookmark
    
Exit_:
    Exit Sub
Err_:
    mc_Log.MC_LogErr ("CM_FormGoToLastRecord()")
    Resume Exit_:
End Sub

mc_Log.MC_LogErr ("FormGoToLastRecord()") — фукнция, которая логирует ошибку в текстовом файле. О ведении лога я как-нибудь расскажу попозже.

CodeContextObject
В процедуре CM_FormGoToLastRecord() используется такая штука, как CodeContextObject, которое в справке называют свойством. Это свойство позволяет получить ссылку на объект, в рамках которого выполняется данный код. Если вызвать процедуру CM_FormGoToLastRecord() в событии подчиненной формы, то CodeContextObject выдаст ссылку на подчиненную форму. Этот же способ использует DoCmd.GoToRecord, когда не указывается имя объекта.

До встречи!

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

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

Written by Сергей Скоков

Май 27th, 2009 at 3:35 пп

Стоит ли использовать временные таблицы для отчетов

Комментариев нет

Здравствуйте, уважаемые читатели.

Отчет

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

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

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

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

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

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

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

До встречи!

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

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

Written by Сергей Скоков

Март 22nd, 2009 at 5:14 пп