Доброго времени суток, коллеги!

Необходимо переслать строку идентификаторов вставленных в БД записей в другой процесс, чтобы
уведомить его о наличие новых записей в таблице. (БД на MS SQL Server 2008 R2).

Подскажите пожалуйста самый простой способ межпроцеснного взаимодействия с точки зрения простоты реализации и минимального объёма кодирования для случаев, когда:

1. Процесс-отправитель сообщения и процесс-примёмник сообщения выполняются на одной машине;
2. Процесс-отправитель сообщения и процесс-примёмник сообщения выполняются на разных машинах в сети;

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

Заранее благодарен!

Здравствуйте, faa, Вы писали:

WCF и named pipes.
http://msdn.microsoft.com/en-us/library/ms752247.aspx

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, faa, Вы писали:

S>WCF и named pipes.
S>http://msdn.microsoft.com/en-us/library/ms752247.aspx

Большое спасибо!

Здравствуйте, faa, Вы писали:

S>>WCF и named pipes.
S>>http://msdn.microsoft.com/en-us/library/ms752247.aspx

faa>Большое спасибо!

Делайте на сокетах и не морочьте себе голову. Потому как только у вас появятся ошибки в сети на стадии 2 — вы проклянете и WCF и named pipes и все высокоуровневые технологии вместе взятые.

Хотя, если это у вас лабораторная — совет хороший

faa>1. Процесс-отправитель сообщения и процесс-примёмник сообщения выполняются на одной машине;

Если только для этого случая, то http://msdn.microsoft.com/en-us/library/bb546102.aspx

Здравствуйте, igor-booch, Вы писали:

IB>Если только для этого случая, то http://msdn.microsoft.com/en-us/library/bb546102.aspx

Не айс -- от .net 4.0 появились.

Здравствуйте, Nikolay_P_I, Вы писали:


N_P>Делайте на сокетах и не морочьте себе голову. Потому как только у вас появятся ошибки в сети на стадии 2 — вы проклянете и WCF и named pipes и все высокоуровневые технологии вместе взятые.

Подробнее можно? Если у нас ошибки в сети, то чем сокеты то лучше.

IB>>Если только для этого случая, то http://msdn.microsoft.com/en-us/library/bb546102.aspx
S>Не айс -- от .net 4.0 появились.

Классы AnonymousPipeServerStream и AnonymousPipeClientStream доступны начиная с версии .net 3.5

Здравствуйте, Sharov, Вы писали:

N_P>>Делайте на сокетах и не морочьте себе голову. Потому как только у вас появятся ошибки в сети на стадии 2 — вы проклянете и WCF и named pipes и все высокоуровневые технологии вместе взятые.

S>Подробнее можно? Если у нас ошибки в сети, то чем сокеты то лучше.

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

Здравствуйте, faa, Вы писали:
faa>1. Процесс-отправитель сообщения и процесс-примёмник сообщения выполняются на одной машине;

1) memory-mapped files

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

Через табличку!

Здравствуйте, RushDevion, Вы писали:

RD>Если процесс-отравитель имеет доступ к, то может проще завести отдельную табличку для уведомлений + тригер на вставку в основную таблицу.
RD>Процесс приемник пусть сам опрашивает с нужной периодичностью.

Такое обычно не подходит по соображениям скорости работы БД. Но, если это не страшно — то можно еще куда в extended property время последнего изменения пихать и мониторить либо вообще у MS SQL есть механизм событий от БД. Для программы выглядит именно как .NET event.