2010-01-17 6 views
0

Je rencontre actuellement des problèmes pour appeler une procédure stockée async à partir d'un déclencheur de mise à jour d'insert. Pour cela, j'utilise le service broker.Procédure stockée SQL Server 2005 Asnyc

--message type 
CREATE MESSAGE TYPE [TheMessage] VALIDATION = NONE 

--contract 
CREATE CONTRACT [TheContract] ([TheMessage] SENT BY ANY); 

--queue 
CREATE QUEUE [TheQueue] WITH ACTIVATION 
(STATUS = ON, MAX_QUEUE_READERS = 1, 
PROCEDURE_NAME = TheStoreProcedure, 
EXECUTE AS OWNER); 

--service 
CREATE SERVICE [TheService] ON QUEUE [TheQueue] ([TheContract]); 

Dans le trigger:

DECLARE @Handle UNIQUEIDENTIFIER; 

BEGIN DIALOG CONVERSATION @Handle 
FROM SERVICE [TheService] 
TO SERVICE 'TheService' 
ON CONTRACT [TheContract] 
WITH ENCRYPTION = OFF; 

SEND ON CONVERSATION @Handle 
MESSAGE TYPE [TheMessage](N'some data'); 

Dans la procédure stockée:

DECLARE @Handle UNIQUEIDENTIFIER; 
DECLARE @MessageType SYSNAME; 

RECEIVE TOP (1) 
@Handle = conversation_handle, 
@MessageType = message_type_name 
FROM [TheQueue]; 

IF(@Handle IS NOT NULL) 

BEGIN 

-- some statements 

END 

Cette configuration ne semble pas fonctionner. Le déclencheur ne renvoie aucune erreur, donc je suppose que le message est en file d'attente. Mais la réception dans le stocké ne semble pas fonctionner. Aucune de mes déclarations n'est en cours d'exécution.

Répondre

0

Ok, merci pour vos réponses, je l'ai corrigé.

Le problème est que le courtier de service a été désactivé ..

USE AdventureWorks 
GO 

ALTER DATABASE AdventureWorks SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
ALTER DATABASE AdventureWorks SET ENABLE_BROKER 
ALTER DATABASE AdventureWorks SET MULTI_USER 
GO 
2
  • Vérifiez si le message n'est pas conservé dans sys.transmission_queue. La colonne Transmission_status devrait expliquer pourquoi le message n'est pas livré.
  • Vérifiez si le message est dans la file d'attente: SELECT ... FROM [TheQueue]. Si le message est présent et que la procédure n'a pas été activée, vérifiez l'état is_receive_enabled de la file d'attente dans sys.service_queues. Si la file d'attente est désactivée, vous avez probablement annulé 5 reçoit dans une rangée pendant le test et a déclenché le poison message mechanism.
  • Si la file d'attente est activée, vérifiez l'état des surveillances de file d'attente, voir Understanding Queue Monitors.
  • Si le message n'est ni dans la file ni dans la file d'attente de transmission, il doit être consommé par la procédure activée. Vérifiez votre ERRORLOG pour toute sortie d'erreur. Désactivez l'activation, envoyez à nouveau un message, puis exécutez la procédure manuellement à partir d'une fenêtre de requête SSMS. Vérifiez si vous obtenez un message d'erreur.
  • Assurez-vous que votre procédure activée ne tombe pas dans les pièges du contexte EXECUTE AS. Voir Why does feature … not work under activation? et Call a procedure in another database from an activated procedure
Questions connexes