Pull to refresh

Comments 17

Не совсем понятно зачем хранить получателей в таблицах, когда есть группы рассылки для почтовых систем
Весьма интересно, приведите пример
Если почтовый адрес пользователя удаляется на почтовом сервере, то отчет может не до ставится получателям вообще, если их несколько при отправке почты из SQL server. Чтобы решить данную проблему создается группа рассылки на почтовом сервере и уже проблема доставки сообщений ложится на email сервер
И как группу настроить на MS SQL Server?
Мы ведь говорим о MS SQL Server, а почтовый сервер я в глаза не видел-этим занимаются системные администраторы.
тут надо работать в команде, я описал случай из своего опыта, когда ваша рассылка работать не будет.
Все-таки давайте конкретнее-приведу алгоритм:
1) на почтовом сервере создается группа рассылки
2) все то, что я описал в статье
Какие будут замечания к п.2 и опишите или дайте ссылку на п.1
1) да, туда сразу включаются нужные почтовые адреса
2) у вас будет только один адрес для отправки сообщений, и из логики вашей работы в п. 1-2 вашего алгоритма отпадает надобность, или сводится к гораздо меньшему числу записей, надо просто более глубоко посмотреть как и что вы используете вашим методом.
За информацию спасибо. Буду иметь это в виду. Просто системные администраторы со стороны заказчиков и молчат, а я о таком не знал. Ваш предложение хорошее. Но мой метод позволяет универсально распространить на все точки и не мучать ни системных админов, компетенция которых некоторых из них оставляет желать лучшего, ни себе-долго объясняя некоторым из них как это делается. И в случае переноса базы обслуживания к другому заказчику тоже меньше работы с системным администратором. Т. е. группы прописать 5 мин. Переносишь к другому заказчику-еще 5 мин., а так ничего не нужно. Но метод, предложенный Вами, все-равно нужно учесть.
Ваш метод хороший, сам такой использовал пока не столкнулся с проблемой удаленный почтовых ящиков, когда часть пользователей получают почту а часть нет. И как мне кажется с точки зрения заказчиков проще добавить в почтовую группу, чем добавлять в таблицу. Тем более если заказчик крупный обычно добавление в группу даже не админ делают, а выделенный сотрудник какого то отдела.
Дело в том, что у нас используются почты наши, т. е. мы обслуживаем базы данных. НО! Вот если им нужно будет что-то слать, то благодаря Вашему предложению, я их пошлю настраивать группы для самих себя, т. к. не хочу отслеживать у кого какие почты меняются. А у нас кто что поменял-сразу заранее сообщает.
Небольшое замечание по поводу форматирования даты/времени. Для этих целей, вероятно, лучше подойдет системная функция FORMAT
FORMAT (Transact-SQL)
Спасибо за совет. Согласен, что приведенный мною подход, был не самым лучшим, буду теперь Вашим предложением пользоваться для формата дат и времени.
Еще небольшое замечание, не очень хорошо что агент «дергает» процедуру достаточно часто раз в минуту, ведь ошибок может и не возникать весьма длительное время. Я бы воспользовался возможностями SQL Server Service Broker и в этом случае доставка сообщений будет действительно realtime и без участия SQL Server Agent.
Идея в следующем:
1. Создаем свой тип сообщения (CREATE MESSAGE TYPE)
2. Создаем контракт (CREATE CONTRACT)
3. Создаем процедуру для отправки сообщений
4. Создаем очередь (CREATE QUEUE), которая использует процедуру из п.3
5. Создаем службу (CREATE SERVICE), которая использует очередь из п.4 и контракт из п.3
Пример
-- активируем service broker
IF NOT EXISTS(SELECT * FROM master.sys.databases WHERE name = DB_NAME() 
			  AND is_broker_enabled = 1)
BEGIN
	DECLARE @sql nvarchar(max);
	SET @sql = N'USE [master]; ALTER DATABASE [' + DB_NAME() +  N'] SET NEW_BROKER; USE [' + DB_NAME() + '];';
	EXECUTE(@sql)
	
	SET @sql = N'USE [master]; ALTER DATABASE [' + DB_NAME() +  N'] SET ENABLE_BROKER; USE [' + DB_NAME() + '];';
	EXECUTE(@sql)
END;
GO

CREATE MESSAGE TYPE [http://tempuri.org/Notifications/SendErrorInfoEvent]
	VALIDATION = WELL_FORMED_XML;
GO
CREATE CONTRACT [http://tempuri.org/Notifications/PostEventNotification] 
(
	[http://tempuri.org/Notifications/SendErrorInfoEvent] SENT BY ANY
);
GO

CREATE PROCEDURE [ProcessNotificationEvents]
AS
BEGIN
	SET NOCOUNT ON;

	DECLARE @message_body XML,
			@message_type_name NVARCHAR(256),
            @dialog UNIQUEIDENTIFIER ;

	WHILE (1 = 1)
	BEGIN
		WAITFOR(
			RECEIVE TOP(1) 
				@message_type_name = message_type_name,
				@message_body = message_body,
				@dialog = conversation_handle
			FROM [EventNotificationQueue]
		), TIMEOUT 2000;

		IF @@ROWCOUNT = 0
		BEGIN
			BREAK;
		END

		IF (@message_type_name = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog')
		BEGIN
	        END CONVERSATION @dialog ;
		END
		ELSE
		BEGIN
			/*
				здесь реальный код обработки сообщения данные в @message_body
			*/
			
			RETURN 0
		END
	END
	RETURN 0;
END
GO
CREATE QUEUE [EventNotificationQueue] WITH 
	STATUS = ON,
	ACTIVATION (
		STATUS = ON, 
		PROCEDURE_NAME = ProcessNotificationEvents, 
		MAX_QUEUE_READERS = 1,
		EXECUTE AS OWNER
	);
GO
CREATE SERVICE [http://tempuri.org/Notifications/EventNotificationService] 
	ON QUEUE [EventNotificationQueue] 
	(
	[http://tempuri.org/Notifications/PostEventNotification] 
	);
GO
--
-- использование, можно оформить в виде процедуры
--
DECLARE @dialog UNIQUEIDENTIFIER;

BEGIN DIALOG CONVERSATION @dialog
	FROM SERVICE [http://tempuri.org/Notifications/EventNotificationService]
	TO SERVICE 'http://tempuri.org/Notifications/EventNotificationService'
	ON CONTRACT [http://tempuri.org/Notifications/PostEventNotification]
	WITH ENCRYPTION = OFF;
	
DECLARE @EventData XML;
-- формируем данные для отправки по электронной почте

SEND ON CONVERSATION @dialog
	MESSAGE TYPE [http://tempuri.org/Notifications/SendErrorInfoEvent] (@EventData);
	
END CONVERSATION @dialog;



В коде могут быть неточности, но идея должны быть понятна.
А Вы пользовались Servie Broker?
Просто как-то пробовали и поняли, что он не для отправки писем, а для общения между серверами.
Поэтому и не стали его использовать.
Конечно не только для отправки писем. Service Broker очень удобная штука, чтобы выполнить какие-то действия асинхронно не снижая производительность пользовательской работы. В одном из проектов (стандартный клиент-сервер) использовал для отправки уведомлений пользователям системы об изменении состояния документов. Отправил сообщение и забыл, дальше работает Service Broker. Простой пример, пользователь отправляет документ на утверждение, при этом руководитель (подразделения, проекта и т.п.) в зависимости от настроек и типа документа должен получить уведомление (в системе, по почте или SMS) о том, что в системе появился документ, который необходимо утвердить. Вот логика формированием и отправкой уведомлений и была реализована с использование Service Broker. Иначе возникали тормоза при выполнении пользовательских действий.
Ну а это уже в качестве развлечения :o). Формирование HTML таблицы при помощи SQL-запроса.

select 
	5 as [BORDER],
	(select TH from (
		values 
		('Column #1'), ('Column #2'), ('Column #3')
	) as T(TH) for xml raw(''), elements, type) as TR,

	(select C1 as TD, C2 as TD, C3 as TD from (
		values 
		('Item 1-1', 'Item 1-2', 'Item 1-3'),
		('Item 2-1', 'Item 2-2', 'Item 2-3')
	) as T(C1, C2, C3) for xml raw('TR'), elements, type)
for xml raw('TABLE')

Sign up to leave a comment.

Articles

Change theme settings