Вопрос на самом деле: о чем оповещать и что с этим оповещением будет делать тот кто его получит?
О чем оповещать?
Если речь идет о оповещении о каких-то событиях в базе данных с точки зрения просто базы(ошибка при добавлении или ошибка целостности) то это одно.
А речь идет, я понимаю, о событиях бизнес-логики и это намного интереснее.
Можно реализовать специальную таблицу для хранения событий оповещений. В ней будут описываться случившиеся события с точки зрения бизнес логики(такой-то документ изменен или такой-то товар оприходован). Каждое событие может характеризоваться типом события(изменение документов, изменение товаров и т.д.) Далее создать таблицу для подписки пользователей на оповещения. Может не всем надо принимать оповещения о товарах, а только о документах. Изменяя информацию в этой таблице, мы управляем кого о чем оповещать.
Далее пишем в эту таблицу события по факту.
А пользователей можно извещать 2 способами
1) Клиентское приложение по таймеру опрашивает эту таблицу и если для текущего пользователя есть события, то выводит их на экран.
2) Посылать по факту события каждому подписанному пользователю сообщение или пакет с кодом, что есть оповещения для него и по этому "пакету" считывать события.

Преимущество такого подхода в том, что когда мы считаем событие мы имеем не просто факт(текст) события, а и полную информацию о нем. Например, пользователь получит событие, "документ изменен"+получит код документа и т.д. и по этому коду может сразу в просмотре оповещения открыть документ, а не просто прочитать текст, что событие произошло.

A.K.
Вот, вы мою мысль верно поняли. Речь именно о событиях бизнес-логики.
Собственно, я такой вариант как у вас выше сам себе уже и предложил - через таблицу оповещений. Просто была слабая надежда, что не придется изобретать велосипед, а удастся заюзать уже реализованные в СУБД специализированные средства.

Я думаю, что не ошибусь, если скажу, что таких специализированных средств нет ни в одной СУБД, т.к. СУБД не оперирует оповещениями на уровне бизнес-логики ибо ничего о ней не знает. Да это и не ее дело.
Средства оповещения конечно есть, но на уровне базы, соединений и т.д. Поэтому везде пишут надстройки именно под бизнес-логику.

В 9 вроде есть процедура sa_send_udp
А так свою Dll написать не проблема и подключить ее к ASA8 в качестве новой функции или процедуры.
Даже красивее механизм получится, чем в цикле опрашивать. Но тут конечно пробовать надо и все продумать.

Это как сказать, про путь решения с таблицами. Как частный случай решения в конкретном случае может он и проще.
Вообще, вопрос, который мы здесь обсуждаем очень интересный, если посмотреть шире.
Тут я бы сказал всплывают некоторые "недостаточки" двухзвеной архитектуры.
А ведь может такое случиться, что у клиента вообще не будет доступа к базе(он ему и не нужен!), а оповещения надо получать гарантировано! И он может, как тут говорили выше, в момент события не подключен к системе оповещений. А подключится потом и должен все получить.
В трехзвенке такие вопросы можно конечно решать более красиво.
Я сколько видел реализаций оповещений в трехзвенке, везде примерно одинаково. Есть сервис оповещений (примерно как ICQ), он работает с клиентами независимо от клиента работы базой через сервер приложений.
Т.к. все операции с базой идут через сервис приложений, то он и взаимодействует с этим сервисом.
А сервис оповещений отслеживает своих клиентов, рассылает им и т.д. База используется им только как хранилище сообщений.
Не стоит забывать, что оповещения(сообщения) в такой системе могут быть и не только по событиям в базе. Например, один пользователь другому сообщение короткое переслал.
Еще хороший вопрос: в каком виде эти оповещения? Можно оповещать по ICQ, по почте и т.д. Реализовать подобное в сервисе оповещений не проблема, а вот в процедурах базы это весьма неудобно.

С ASA наверно такое можно тоже реализовать и без сервера приложений. Только и тут без некого сервиса оповещений не обойтись наверно. Но в каждом конкретном случае нужно конечно смотреть на задачу, может это все лишнее будет.

Все это я тут высказал конечно в порядке рассуждений на "тему".

to A.K.
Про средства в Oracle не знал. Cейчас конечно в разных СУБД много чего сделали.
Про написание корпоративной ICQ речь не шла абсолютно. В том-то и дело, она написана, только пользуйся.
Я имел ввиду, что ICQ может выступать только как одно из средств оповещения наравне с почтой и другими. И согласитесь было бы глупо ими не пользоваться.
Но вот напрямую из ASA со всеми этими средствами разом работать не очень будет удобно, да и не его это дело.
Гораздо проще в этом случае как раз иметь некий сервис оповещений, с которым будет взаимодействовать ASA (с этим сервисом кстати может взаимодействовать кто и что угодно для посылки оповещений) и который уже далее будет работать с клиентами системы оповещения по ICQ, Почте и т.д.
Я конечно говорю про сложный пример системы, с разными средствами оповещений пользователей, с кучей событий бизнес-логики(не только в базе) и т.д.
Я конечно зря упомянул выше про "трехзвенку", здесь несколько иное - сервисы. Есть сервис базы, есть сервис оповещений и каждый должен заниматься своим делом.
В вашем случае наверно все проще, поэтому и такой сложный подход не требуется.
Ну ладно, увлекся немного. Тема уже другим форумом попахивает.
Удачно Вам всех оповестить!

P.S. А ветку из другого форума даже перечитал, спасибо. Споры действительно жаркие.