Под парадоксом - никак.
Общий принцип построения аудита действий юзера примерно такой.

Каждому юзеру призваивается уникальный идентификатор. Этот идентификатор подгружается или из таблицы, или из текстового файла в Privat директории. В таблицу данных добавляется поле UserID.
Когда юзер добавляет запись в таблицу, в нее всегда должен записываться его ID. Если добавление записи идет из DBControls, то это присвоение можно сделать в BeforInsert.

Создаем таблу аудита. В нее, кроме полей таблицы данных добавляем поля UserID,cUserID и датувремя.

При изменении данных записываем в нее изменяемую строку с неизмененными данными, в поле cUserID - ID юзера изменившего данные и текушее время. Если изменение записи идет из DBControls, то эту вставку можно сделать в BeforPost.

При удалении записи записываем в таблу аудита удалаяемую строку, в поле cUserID - ID юзера удалившего данные и текушее время. Если удаление записи идет из DBControls, то эту вставку можно сделать в BeforDelete.

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

Все правильно.
Возможность реализации такого механизма присутствует только в клиент-серверных базах. Там есть тригера которые позволяют отслеживать действия пользователей. Как минимум - вставку/изменение/удаление записей. В БД прямого доступа этого не может быть по определению. Клиент таких БД САМ делает изменения в таблицах и, следовательно, может использовать только СВОИ события. Что является нормальным способом работы.