SQL 2008 - альтернатива триггеру

Question

Я ищу решение для следующего:

База данных: A
Таблица: InvoiceLines

База данных: B
Таблица: MyLog

Каждый раз, когда строки добавляются в InvoiceLines в базе данных A, я хочу выполнить запрос, который обновляет таблицу MyLog в базе данных B. И я хочу это немедленно.

Обычно я бы создал триггер в базе данных A на INSERT в InvoiceLines. Проблема в том, что база данных A принадлежит программе ERP, в которой я вообще не хочу вносить какие-либо изменения (обновления, неизвестные функции в трехслойной программе и т. Д.)

Любые намеки, чтобы помочь мне в правильном направлении ...?

Answer 1

Вы можете использовать транзакционную репликацию для отправки изменений из вашей таблицы в базе данных A в копию в БД B, а затем создать свои триггеры на копии. Это не «мгновенно», но обычно считается «почти в реальном времени».

Возможно, вы сможете использовать зеркалирование БД для этого, но вам нужно будет провести некоторое тестирование, чтобы убедиться, что вы можете заставить его работать правильно (возможно, настроить триггеры в зеркале, которых нет в оригинал?)

Answer 2

Одним из возможных решений для репликации функций триггера без обновления базы данных является опрос таблицы внешним приложением (например, java), которое при обнаружении новой вставки будет запускать требуемый запрос.

В SQLServer2008 нечто подобное можно сделать через сборку C #, но, опять же, его необходимо установить, что требует обновления базы данных.

Answer 3

Триггер в одной базе данных может обновить другую.

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

Insert into MyOtherDB..MyLogTable select ... From Inserted 

или

Exec MyOtherDB..LogInsert(@p1,@p2)

например

Редактировать после комментария ...

Без изменений вообще ...

. SQLDependency класс .net даст вам один способ, если вы хотите написать приложение.

Подобным, но, к сожалению, неэффективным было бы выполнение запланированного хранимого процесса в базе данных, который искал изменения в A и действовал соответствующим образом.