Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / After/Before Update / 8 сообщений из 8, страница 1 из 1
20.01.2016, 12:29
    #39151313
Casper2002
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Казалось бы задача тривиальная, но прозрачного ответа на свой вопрос пока не нашел. Имеется таблица, которую редактируют множество пользователей на главной форме. Необходимо выловить, кем, какое поле и запись была отредактирована.

Как получить пользователя понятно - функция Application.CurrentUser. Также ясно, что перехватывать события нужно через After/Before Update формы. Как сделать все остальное не ясно...
...
Рейтинг: 0 / 0
20.01.2016, 13:15
    #39151357
MrShin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Советую посмотреть в сторону Data Macro, в частности Before Change . Вся требуемя информация доступна там, можно вызывать VBA функции. Обязательно нужно предусмотреть отключение кода флагом, ибо тормозит это прилично. Не очень красиво еще получится выявление поля, которое редактировалось, придется перечислять все поля в IF-ах или аналоге
...
Рейтинг: 0 / 0
20.01.2016, 13:23
    #39151370
Predeclared
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Casper2002... таблица, которую редактируют ...
Ошибки при проектировании.

В идеальном случае, записи должны только добавляться.
Редактирование записи только в редких случаях, коррекция ошибок ввода и т.п.
...
Рейтинг: 0 / 0
20.01.2016, 13:25
    #39151377
Slavinag
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Если база на SQL, то журнализацию я бы прикрутил на соответствующие триггеры таблиц/вьюшек.
...
Рейтинг: 0 / 0
20.01.2016, 15:25
    #39151553
Сергей Лалов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Casper2002Казалось бы задача тривиальная, но прозрачного ответа на свой вопрос пока не нашел. Имеется таблица, которую редактируют множество пользователей на главной форме. Необходимо выловить, кем, какое поле и запись была отредактирована.

Как получить пользователя понятно - функция Application.CurrentUser. Также ясно, что перехватывать события нужно через After/Before Update формы. Как сделать все остальное не ясно...


Как быстрый вариант решения задачи в access: На основные события записей формы Form_AfterUpdate() и Form_Delete(Cancel As Integer) пишете простой запрос на добавление записи в дополнительную таблицу (назовем её "логи") .
В таблице "логи" должны присутствовать абсолютно все поля ,которые есть в изменяемой таблице.
Плюс в таблице "логи" добавляете два дополнительных поля - ТипДействия и Пользователь


При срабатывании события обновления в логи добавляется измененная запись , в поле ТипДействия вставляется текст "изменение" . В поле Пользователь вставляется Application.CurrentUser
При срабатывании события удаление в логи добавляется удаленная запись , в поле ТипДействия вставляется текст "удаление" .
В поле Пользователь вставляется Application.CurrentUser

Простенький образец склепал и приложил (на форме измените какуюнить запись,или удалите, а потом посмотрите таблицу логи). В реальности логи лучше не хранить в аксесовской таблице а выгружать в какойнить сторонний файл txt или xml. Самое главное поймите логику работы.
...
Рейтинг: 0 / 0
20.01.2016, 15:53
    #39151581
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Casper2002 , у Вас явная идеологическая недосказанность.

Самым простым было бы безусловно блокировать запись, взятую пользователем на изменение. Если один пользователь открыл запись для изменения - остальные получают отказ (плюс, возможно, уведомление, кем заблокирована запись).

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

В любом случае настоятельно рекомендую исключить использование в качестве источника данных формы непосредственно таблицы.
...
Рейтинг: 0 / 0
20.01.2016, 16:16
    #39151610
Сергей Лалов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Akina Casper2002 ,
В любом случае настоятельно рекомендую исключить использование в качестве источника данных формы непосредственно таблицы.

В принципе, начиная с 2010 версии аксесс есть удобный инструмент ведения статистики. Реализовали триггеры на уровне таблиц. Можно отслеживать изменения с уровня таблиц, не привязываясь к формам. На любителя.
...
Рейтинг: 0 / 0
20.01.2016, 16:25
    #39151620
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
After/Before Update
Сергей Лалов , ну это неплохо, когда начинается "разбор полётов". А в качестве инструмента арбитража я бы не рекомендовал...
...
Рейтинг: 0 / 0
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / After/Before Update / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]