Showing posts with label working. Show all posts
Showing posts with label working. Show all posts

Friday, March 30, 2012

Remove Duplicate value from One Cloumn Table

I am working SQL Server 2005 and One Table Which contain only one column without primary key
Now I want to remove all duplicate value from that table with only single query
Here are a couple options:
http://www.sqlteam.com/item.asp?ItemID=3331
http://support.microsoft.com/default.aspx?scid=kb;en-us;139444
|||

Thank

Here happens like that

1) Select Distinct row from the original table and store it into tempory table

2) delete all rows from original table

3) copy the all rows from tempory table (where distinct rows inserted)

But I want to do this thing using single Delete Query
Can we do this by using only single delete query

sql

Friday, March 23, 2012

remoted linked server problem

I am running SQL 2005 trigger and update the table in remote linked server. This is working perfectly when the firewall is off. However when I turn on the firewall, it wont run any more. I need the firewall on for the security issue. How can I run this trigger with firewall on? Thanks.Do not create triggers that operate outside the scope of their own database.|||Do not create triggers that operate outside the scope of their own database.

+1

hmscott

Wednesday, March 21, 2012

Remote tables

Hi everybody:

I am working on a query that referrences a table in a remote database. It seems in Management Studio 2005 anytime you open a new query window you should connect to a specific database instance that's why when I refer to the remote database table using Fully Qualified Name it tells me the database name is unknown.

Do you have any solutions for this?

Thanks a lot

Which qualified name did you use ?


HTH, jens Suessmeyer.


http://www.sqlserver2005.de

|||

[server].[database].[owner].[table]

|||Hi,

if you connect to a database / server you can reach any (linked) server and therefore remote database that are setup on the server machine. You don′t need to specify the remoteserver at connection time, that why you can specify it the four part name:

[server].[database].[owner].[table]

But the [server] has to be a linked server. If you don′t know how to setup, look in the BOl there are some good straight forward examples for it.

HTH, jens Suessmeyer.

http//www.sqlserver2005.de

|||

You can try with OPENROWSET or OPENQUERY function. To do this you need to enable this features from "SQL Server Surface Area Configuration" - Ad Hoc Remote Queries (you need to check "Enable OPENROWSET and OPENDATASOURCE). After you enable this option you can use this function to retrieve data from another server or to get data from another format (including MS Excel - for example).

SELECT a.* FROM OPENROWSET('SQLNCLI', 'Server=Seattle1;Trusted_Connection=yes;', 'SELECT GroupName, Name, DepartmentID FROM AdventureWorks.HumanResources.Department ORDER BY GroupName, Name') AS a;

Remote SQL Server 2000 Perfmon Not Working

I have a SQL Server 2000 cluster running on x64 OS. I found the threads in the forum to run perfmon locally by using the x86 version of perfmon (mmc /32 perfmon). However, I cannot run a perfmon remotely from another machine and see the SQL Server perfmon data on any of the nodes in the cluster. The remote perfmon picks up all of the other perfmon variables but no SQL.

I found another thread where somebody asked this question but it wasn't answered. Thanks in advance.

Mark

there is no x64 counter.|||Absolutely correct. There is no x64 SQL 2000 counter which is why one must run the 32-bit version of perfmon. I can run the 32-bit perfmon locally on my cluster nodes and see the 32-bit SQL performance counters but I am unable to run perfmon from a remote machine, connect to one of my cluster nodes and see the SQL counters.|||

What do you mean by "remote computer"? Are you trying to do this across the Internet or VPN or what?

Perfmon depends on the "named pipes" protocol and will never work across the Internet because NetBios is blocked by most ISPs.

|||

We are in the process of setting up Operations Manager to collect perf data. Until then we are stuck with a management server that has perfmon running on it centrally collecting data from various servers. I can see other performance counters, just not the ones for SQL Server.

The management server and the SQL cluster are on the same LAN/subnet without any type of firewall between them. I have a test cluster that is doing the exact same thing. Sad

Tuesday, March 20, 2012

Remote Server / Linked Server

I have transactional replication working and it created a remote server
to be used for replication. I am not able to insert/delete/update
between the two servers through the "remote server" connection. I need
to use a linked server, do I need to set up this linked server prior to
configuring any replication so a remote server isn't created during
configuration? Is there something else I can do instead of this.
Thanks
sp_serveroption 'remoteServerName','data access',true
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"billy_karnes" <billy_karnes@.corphealth.com> wrote in message
news:1142538888.208897.59030@.e56g2000cwe.googlegro ups.com...
>I have transactional replication working and it created a remote server
> to be used for replication. I am not able to insert/delete/update
> between the two servers through the "remote server" connection. I need
> to use a linked server, do I need to set up this linked server prior to
> configuring any replication so a remote server isn't created during
> configuration? Is there something else I can do instead of this.
> Thanks
>
|||I changed the data access to true, but now I get the following error
Msg 18452, Level 14, State 1, Line 1
Login failed for user '(null)'. Reason: Not associated with a trusted
SQL Server connection.
The security properties are set to: "Be made using the login's current
security context"
I have sysadmin priviledges so I shouldn't be restricted by that. I
can get it to work and pull data, if I change the security properties
to use the sa login and password, but that isn't secure enough. What
options do I have. Thanks for your time.
|||Enter the sa account and password on the linked server.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"billy_karnes" <billy_karnes@.corphealth.com> wrote in message
news:1142872805.003828.93830@.t31g2000cwb.googlegro ups.com...
>I changed the data access to true, but now I get the following error
> Msg 18452, Level 14, State 1, Line 1
> Login failed for user '(null)'. Reason: Not associated with a trusted
> SQL Server connection.
> The security properties are set to: "Be made using the login's current
> security context"
> I have sysadmin priviledges so I shouldn't be restricted by that. I
> can get it to work and pull data, if I change the security properties
> to use the sa login and password, but that isn't secure enough. What
> options do I have. Thanks for your time.
>
|||Maybe I didn't state my question correctly. I am wanting to use the
security property of: "Be made using the login's current
security context" so it can limit the users priviledges to the other
server. When I do this I get the following error.
Msg 18452, Level 14, State 1, Line 1
Login failed for user '(null)'. Reason: Not associated with a trusted
SQL Server connection
I was able to use the sa login and password, but that allowed everyone
to have unlimited access to the linked server.
How do I get the security property of: "Be made using the login's
current security context" to work without getting the error. Thanks
|||I don't believe you can as you are logging on using Windows Authentication,
and it appears that the remote server is not part of the domain. Perhaps try
pass through authentication. By any chance is the remote server across the
internet?
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"billy_karnes" <billy_karnes@.corphealth.com> wrote in message
news:1142879939.773655.304440@.z34g2000cwc.googlegr oups.com...
> Maybe I didn't state my question correctly. I am wanting to use the
> security property of: "Be made using the login's current
> security context" so it can limit the users priviledges to the other
> server. When I do this I get the following error.
> Msg 18452, Level 14, State 1, Line 1
> Login failed for user '(null)'. Reason: Not associated with a trusted
> SQL Server connection
>
> I was able to use the sa login and password, but that allowed everyone
> to have unlimited access to the linked server.
>
> How do I get the security property of: "Be made using the login's
> current security context" to work without getting the error. Thanks
>

Friday, March 9, 2012

Remote messages not working – message vanishes

I need some assistance with getting service broker to work across servers. I have 2 separate servers and I am trying to send a message from one server to the other. No error is generated when sending the message and I get no records in the transmission queue of the sending server, however the message does not arrive on the receiving server. Where is the message going?

Here is the code I use to create the service broker objects that are being used…

RUN THIS ON THE SENDING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyInitiatorService] ON QUEUE [MyInitiatorQueue]

GO

CREATE ROUTE [RouteToODS]

WITH

SERVICE_NAME = N'MyTargetService',

BROKER_INSTANCE = '1BB213E2-67A7-4059-BAF8-D9B5F31E358E',

ADDRESS = N'TCP://CONSULT01:4022'

GO

CREATE ENDPOINT DWHEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

RUN THIS ON THE RECEIVING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyTargetService] ON QUEUE [MyTargetQueue] ([MyContract])

GO

CREATE ROUTE [RouteToDWH]

WITH

SERVICE_NAME = N'MyInitiatorService',

BROKER_INSTANCE = 'F0BF4E80-704E-4CFE-80FC-637A1EC128C5',

ADDRESS = N'TCP://DWH:4022'

GO

CREATE ENDPOINT ODSEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

SEND A MESSAGE USING THE FOLLOWING:

Declare @.ConversationHandle uniqueidentifier

Begin Transaction

Begin Dialog @.ConversationHandle

From Service [MyInitiatorService]

To Service 'MyTargetService'

On Contract [MyContract]

With Encryption = Off,

Lifetime = 600;

Send on Conversation @.ConversationHandle

Message Type [MyMessage] (N'This is a my message')

End Conversation @.ConversationHandle

Commit

Select GET_TRANSMISSION_STATUS(@.ConversationHandle)

I've done a bit more in trying to resolve the issue and I'm more confused than ever...

As per the Service Broker Routing article on MSDN I have removed the route from the database of the target server and created it in MSDB instead. After doing that the message now remains in the transmission queue of the sending server but without any error (transmission_status is blank). However when I look at the summary report of Service Broker on the sending server under #Messages in Transmission Queue it shows 2 messages and “MyInitiatorService(Non existent service)” in the key to the graph. If there was a problem with the service why would it not show the error in the transmission queue, and what is the problem with the service?

|||I don't know what routing article you mention, but you should definitely have a route both on the sending side as well as on the receiving side - in the databases, not in MSDB.

Also, take out the END CONVERSATION after you have send. End conversation kills the conversation and discards un-send messages. That's probably why you don't see a message in the sys.transmission_queue.

Niels|||

Most likely your message reaches the target, it gets denied access on the service (since you use unsecure dialogs and you don't grant SEND permission to [Public]), the error comes back and then the dialog gets deleted, since you already ended it.

1. Grant SEND permission to [Public] on the target service
2. Don't end the dialog on the initiator side prematurely

HTH,
~ Remus

|||

BTW, you could try following the steps from this article to identify the problem: http://blogs.msdn.com/remusrusanu/archive/2005/12/20/506221.aspx

HTH,
~ Remus

|||

Niels, End conversation does not discard pending messages. However, once you have closed the conversation on your end, you will no longer be able to receive response messages, including errors sent back by target (eg> sender does not have permission to send to this target service).

Flamin, therefore you should not end conversation at the initiator until you've confirmed that it has been delivered to the target service.

Rushi

|||

Thanks for the clarification on End Conversation, I didn’t know that ending the conversation would block errors too. As soon as I removed the End Conversation I received a permissions error. As you suspected Remus the problem was due to a lack of send permissions on the service.

|||

Hi Remus,

I am facing problem which is somewhat related to this it will be great if you can help me in resolving it. Actually for me every thing is working fine in the sense i am able to send and receive the messages.

But i see their are so many messages which are stuck up in sys.conversation_endpoints table. All this messages are having state as DI and initiator as 0.

As i am sending number of messages using same queue i am not able to get to the route of the cause due to which messages are getting stuck up.

Even i am ending conversation on initiator end so can that be the reason for the issue.

Please let me know if you need any more information from me.

Thanks

|||

Those are not messages, but conversation endpoints. DI state for is_initiator = 0 means that you receive EndDialog message on the target, but you don't end the target endpoint of the dialog. To completely close, a conversation must be ended by both conversation endpoints (initiator and target). Typicaly this means than wehn the RECEIVE returns a message of type [http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog] you should issue END CONVERSATION on the received handle.

HTH,
~ Remus

|||

Thanks for your suggestions

But the real issue is when and how should i delete those records from target end.

This is how i am sending message

SELECT @.SendService = '//'+@.Pod_ID+'/TransactionQueue',
@.ReceiveService = '//ODS/'+@.Pod_ID+'/TransactionQueue',
@.Contract = '//Contract/TransactionQueue';

BEGIN DIALOG CONVERSATION @.handle
FROM SERVICE @.SendService
TO SERVICE @.ReceiveService
ON CONTRACT @.Contract;

SEND ON CONVERSATION @.handle
MESSAGE TYPE @.xmlMessageType(@.xmlMessage);

END CONVERSATION @.handle;

And this is how i am processing the message on target end

RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;

I am having a code

IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
RETURN 0
END

Which i thought is creating problem. But i see their are no records with this message type in TransactionQueue (user defined queue) and sys.transmission_queue (system queue).

I am still curious to know how can i get rid of those records from conversation_endpoints. As the count is growing like anything.

Just one more question. If solution is ending conversation on target end, which approach should i follow

1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

2: IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

TIA

Prashant

|||

In case 1, you are ending the dialog regardless of the type of message received. If you expect more than one message interaction, there will be no way to receive more messages.

In case 2, you are ending the dialog only when the initiator has closed the dialog and you know for sure, no more messages are expected.

Also, let me warn you that the pattern you are using (which we call fire-and-forget), where the initiator begins a dialog, sends a message and ends the conversation can be problematic for two main reasons:

i) There is no app-level reliability, i.e. without getting a response back, the initiating app will never know whether its message was processed or not.

ii) During development, you will not be able to see error messages sent back by the target.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

Remote messages not working – message vanishes

I need some assistance with getting service broker to work across servers. I have 2 separate servers and I am trying to send a message from one server to the other. No error is generated when sending the message and I get no records in the transmission queue of the sending server, however the message does not arrive on the receiving server. Where is the message going?

Here is the code I use to create the service broker objects that are being used…

RUN THIS ON THE SENDING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyInitiatorService] ON QUEUE [MyInitiatorQueue]

GO

CREATE ROUTE [RouteToODS]

WITH

SERVICE_NAME = N'MyTargetService',

BROKER_INSTANCE = '1BB213E2-67A7-4059-BAF8-D9B5F31E358E',

ADDRESS = N'TCP://CONSULT01:4022'

GO

CREATE ENDPOINT DWHEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

RUN THIS ON THE RECEIVING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyTargetService] ON QUEUE [MyTargetQueue] ([MyContract])

GO

CREATE ROUTE [RouteToDWH]

WITH

SERVICE_NAME = N'MyInitiatorService',

BROKER_INSTANCE = 'F0BF4E80-704E-4CFE-80FC-637A1EC128C5',

ADDRESS = N'TCP://DWH:4022'

GO

CREATE ENDPOINT ODSEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

SEND A MESSAGE USING THE FOLLOWING:

Declare @.ConversationHandle uniqueidentifier

Begin Transaction

Begin Dialog @.ConversationHandle

From Service [MyInitiatorService]

To Service 'MyTargetService'

On Contract [MyContract]

With Encryption = Off,

Lifetime = 600;

Send on Conversation @.ConversationHandle

Message Type [MyMessage] (N'This is a my message')

End Conversation @.ConversationHandle

Commit

Select GET_TRANSMISSION_STATUS(@.ConversationHandle)

I've done a bit more in trying to resolve the issue and I'm more confused than ever...

As per the Service Broker Routing article on MSDN I have removed the route from the database of the target server and created it in MSDB instead. After doing that the message now remains in the transmission queue of the sending server but without any error (transmission_status is blank). However when I look at the summary report of Service Broker on the sending server under #Messages in Transmission Queue it shows 2 messages and “MyInitiatorService(Non existent service)” in the key to the graph. If there was a problem with the service why would it not show the error in the transmission queue, and what is the problem with the service?

|||I don't know what routing article you mention, but you should definitely have a route both on the sending side as well as on the receiving side - in the databases, not in MSDB.

Also, take out the END CONVERSATION after you have send. End conversation kills the conversation and discards un-send messages. That's probably why you don't see a message in the sys.transmission_queue.

Niels|||

Most likely your message reaches the target, it gets denied access on the service (since you use unsecure dialogs and you don't grant SEND permission to [Public]), the error comes back and then the dialog gets deleted, since you already ended it.

1. Grant SEND permission to [Public] on the target service
2. Don't end the dialog on the initiator side prematurely

HTH,
~ Remus

|||

BTW, you could try following the steps from this article to identify the problem: http://blogs.msdn.com/remusrusanu/archive/2005/12/20/506221.aspx

HTH,
~ Remus

|||

Niels, End conversation does not discard pending messages. However, once you have closed the conversation on your end, you will no longer be able to receive response messages, including errors sent back by target (eg> sender does not have permission to send to this target service).

Flamin, therefore you should not end conversation at the initiator until you've confirmed that it has been delivered to the target service.

Rushi

|||

Thanks for the clarification on End Conversation, I didn’t know that ending the conversation would block errors too. As soon as I removed the End Conversation I received a permissions error. As you suspected Remus the problem was due to a lack of send permissions on the service.

|||

Hi Remus,

I am facing problem which is somewhat related to this it will be great if you can help me in resolving it. Actually for me every thing is working fine in the sense i am able to send and receive the messages.

But i see their are so many messages which are stuck up in sys.conversation_endpoints table. All this messages are having state as DI and initiator as 0.

As i am sending number of messages using same queue i am not able to get to the route of the cause due to which messages are getting stuck up.

Even i am ending conversation on initiator end so can that be the reason for the issue.

Please let me know if you need any more information from me.

Thanks

|||

Those are not messages, but conversation endpoints. DI state for is_initiator = 0 means that you receive EndDialog message on the target, but you don't end the target endpoint of the dialog. To completely close, a conversation must be ended by both conversation endpoints (initiator and target). Typicaly this means than wehn the RECEIVE returns a message of type [http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog] you should issue END CONVERSATION on the received handle.

HTH,
~ Remus

|||

Thanks for your suggestions

But the real issue is when and how should i delete those records from target end.

This is how i am sending message

SELECT @.SendService = '//'+@.Pod_ID+'/TransactionQueue',
@.ReceiveService = '//ODS/'+@.Pod_ID+'/TransactionQueue',
@.Contract = '//Contract/TransactionQueue';

BEGIN DIALOG CONVERSATION @.handle
FROM SERVICE @.SendService
TO SERVICE @.ReceiveService
ON CONTRACT @.Contract;

SEND ON CONVERSATION @.handle
MESSAGE TYPE @.xmlMessageType(@.xmlMessage);

END CONVERSATION @.handle;

And this is how i am processing the message on target end

RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;

I am having a code

IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
RETURN 0
END

Which i thought is creating problem. But i see their are no records with this message type in TransactionQueue (user defined queue) and sys.transmission_queue (system queue).

I am still curious to know how can i get rid of those records from conversation_endpoints. As the count is growing like anything.

Just one more question. If solution is ending conversation on target end, which approach should i follow

1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

2: IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

TIA

Prashant

|||

In case 1, you are ending the dialog regardless of the type of message received. If you expect more than one message interaction, there will be no way to receive more messages.

In case 2, you are ending the dialog only when the initiator has closed the dialog and you know for sure, no more messages are expected.

Also, let me warn you that the pattern you are using (which we call fire-and-forget), where the initiator begins a dialog, sends a message and ends the conversation can be problematic for two main reasons:

i) There is no app-level reliability, i.e. without getting a response back, the initiating app will never know whether its message was processed or not.

ii) During development, you will not be able to see error messages sent back by the target.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

Remote messages not working – message vanishes

I need some assistance with getting service broker to work across servers. I have 2 separate servers and I am trying to send a message from one server to the other. No error is generated when sending the message and I get no records in the transmission queue of the sending server, however the message does not arrive on the receiving server. Where is the message going?

Here is the code I use to create the service broker objects that are being used…

RUN THIS ON THE SENDING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyInitiatorService] ON QUEUE [MyInitiatorQueue]

GO

CREATE ROUTE [RouteToODS]

WITH

SERVICE_NAME = N'MyTargetService',

BROKER_INSTANCE = '1BB213E2-67A7-4059-BAF8-D9B5F31E358E',

ADDRESS = N'TCP://CONSULT01:4022'

GO

CREATE ENDPOINT DWHEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

RUN THIS ON THE RECEIVING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyTargetService] ON QUEUE [MyTargetQueue] ([MyContract])

GO

CREATE ROUTE [RouteToDWH]

WITH

SERVICE_NAME = N'MyInitiatorService',

BROKER_INSTANCE = 'F0BF4E80-704E-4CFE-80FC-637A1EC128C5',

ADDRESS = N'TCP://DWH:4022'

GO

CREATE ENDPOINT ODSEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

SEND A MESSAGE USING THE FOLLOWING:

Declare @.ConversationHandle uniqueidentifier

Begin Transaction

Begin Dialog @.ConversationHandle

From Service [MyInitiatorService]

To Service 'MyTargetService'

On Contract [MyContract]

With Encryption = Off,

Lifetime = 600;

Send on Conversation @.ConversationHandle

Message Type [MyMessage] (N'This is a my message')

End Conversation @.ConversationHandle

Commit

Select GET_TRANSMISSION_STATUS(@.ConversationHandle)

I've done a bit more in trying to resolve the issue and I'm more confused than ever...

As per the Service Broker Routing article on MSDN I have removed the route from the database of the target server and created it in MSDB instead. After doing that the message now remains in the transmission queue of the sending server but without any error (transmission_status is blank). However when I look at the summary report of Service Broker on the sending server under #Messages in Transmission Queue it shows 2 messages and “MyInitiatorService(Non existent service)” in the key to the graph. If there was a problem with the service why would it not show the error in the transmission queue, and what is the problem with the service?

|||I don't know what routing article you mention, but you should definitely have a route both on the sending side as well as on the receiving side - in the databases, not in MSDB.

Also, take out the END CONVERSATION after you have send. End conversation kills the conversation and discards un-send messages. That's probably why you don't see a message in the sys.transmission_queue.

Niels|||

Most likely your message reaches the target, it gets denied access on the service (since you use unsecure dialogs and you don't grant SEND permission to [Public]), the error comes back and then the dialog gets deleted, since you already ended it.

1. Grant SEND permission to [Public] on the target service
2. Don't end the dialog on the initiator side prematurely

HTH,
~ Remus

|||

BTW, you could try following the steps from this article to identify the problem: http://blogs.msdn.com/remusrusanu/archive/2005/12/20/506221.aspx

HTH,
~ Remus

|||

Niels, End conversation does not discard pending messages. However, once you have closed the conversation on your end, you will no longer be able to receive response messages, including errors sent back by target (eg> sender does not have permission to send to this target service).

Flamin, therefore you should not end conversation at the initiator until you've confirmed that it has been delivered to the target service.

Rushi

|||

Thanks for the clarification on End Conversation, I didn’t know that ending the conversation would block errors too. As soon as I removed the End Conversation I received a permissions error. As you suspected Remus the problem was due to a lack of send permissions on the service.

|||

Hi Remus,

I am facing problem which is somewhat related to this it will be great if you can help me in resolving it. Actually for me every thing is working fine in the sense i am able to send and receive the messages.

But i see their are so many messages which are stuck up in sys.conversation_endpoints table. All this messages are having state as DI and initiator as 0.

As i am sending number of messages using same queue i am not able to get to the route of the cause due to which messages are getting stuck up.

Even i am ending conversation on initiator end so can that be the reason for the issue.

Please let me know if you need any more information from me.

Thanks

|||

Those are not messages, but conversation endpoints. DI state for is_initiator = 0 means that you receive EndDialog message on the target, but you don't end the target endpoint of the dialog. To completely close, a conversation must be ended by both conversation endpoints (initiator and target). Typicaly this means than wehn the RECEIVE returns a message of type [http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog] you should issue END CONVERSATION on the received handle.

HTH,
~ Remus

|||

Thanks for your suggestions

But the real issue is when and how should i delete those records from target end.

This is how i am sending message

SELECT @.SendService = '//'+@.Pod_ID+'/TransactionQueue',
@.ReceiveService = '//ODS/'+@.Pod_ID+'/TransactionQueue',
@.Contract = '//Contract/TransactionQueue';

BEGIN DIALOG CONVERSATION @.handle
FROM SERVICE @.SendService
TO SERVICE @.ReceiveService
ON CONTRACT @.Contract;

SEND ON CONVERSATION @.handle
MESSAGE TYPE @.xmlMessageType(@.xmlMessage);

END CONVERSATION @.handle;

And this is how i am processing the message on target end

RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;

I am having a code

IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
RETURN 0
END

Which i thought is creating problem. But i see their are no records with this message type in TransactionQueue (user defined queue) and sys.transmission_queue (system queue).

I am still curious to know how can i get rid of those records from conversation_endpoints. As the count is growing like anything.

Just one more question. If solution is ending conversation on target end, which approach should i follow

1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

2: IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

TIA

Prashant

|||

In case 1, you are ending the dialog regardless of the type of message received. If you expect more than one message interaction, there will be no way to receive more messages.

In case 2, you are ending the dialog only when the initiator has closed the dialog and you know for sure, no more messages are expected.

Also, let me warn you that the pattern you are using (which we call fire-and-forget), where the initiator begins a dialog, sends a message and ends the conversation can be problematic for two main reasons:

i) There is no app-level reliability, i.e. without getting a response back, the initiating app will never know whether its message was processed or not.

ii) During development, you will not be able to see error messages sent back by the target.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

Remote messages not working – message vanishes

I need some assistance with getting service broker to work across servers. I have 2 separate servers and I am trying to send a message from one server to the other. No error is generated when sending the message and I get no records in the transmission queue of the sending server, however the message does not arrive on the receiving server. Where is the message going?

Here is the code I use to create the service broker objects that are being used…

RUN THIS ON THE SENDING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyInitiatorService] ON QUEUE [MyInitiatorQueue]

GO

CREATE ROUTE [RouteToODS]

WITH

SERVICE_NAME = N'MyTargetService',

BROKER_INSTANCE = '1BB213E2-67A7-4059-BAF8-D9B5F31E358E',

ADDRESS = N'TCP://CONSULT01:4022'

GO

CREATE ENDPOINT DWHEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

RUN THIS ON THE RECEIVING SERVER:

CREATE MESSAGE TYPE [MyMessage] VALIDATION = NONE

CREATE MESSAGE TYPE [MyResponse] VALIDATION = NONE

GO

CREATE CONTRACT [MyContract] (

MyMessage SENT BY INITIATOR,

MyResponse SENT BY TARGET)

GO

CREATE QUEUE [MyInitiatorQueue] with status = ON

CREATE QUEUE [MyTargetQueue] with status = ON

GO

CREATE SERVICE [MyTargetService] ON QUEUE [MyTargetQueue] ([MyContract])

GO

CREATE ROUTE [RouteToDWH]

WITH

SERVICE_NAME = N'MyInitiatorService',

BROKER_INSTANCE = 'F0BF4E80-704E-4CFE-80FC-637A1EC128C5',

ADDRESS = N'TCP://DWH:4022'

GO

CREATE ENDPOINT ODSEndPoint

STATE = STARTED

AS TCP (LISTENER_PORT = 4022)

FOR SERVICE_BROKER (

AUTHENTICATION = WINDOWS,

ENCRYPTION = DISABLED)

GO

SEND A MESSAGE USING THE FOLLOWING:

Declare @.ConversationHandle uniqueidentifier

Begin Transaction

Begin Dialog @.ConversationHandle

From Service [MyInitiatorService]

To Service 'MyTargetService'

On Contract [MyContract]

With Encryption = Off,

Lifetime = 600;

Send on Conversation @.ConversationHandle

Message Type [MyMessage] (N'This is a my message')

End Conversation @.ConversationHandle

Commit

Select GET_TRANSMISSION_STATUS(@.ConversationHandle)

I've done a bit more in trying to resolve the issue and I'm more confused than ever...

As per the Service Broker Routing article on MSDN I have removed the route from the database of the target server and created it in MSDB instead. After doing that the message now remains in the transmission queue of the sending server but without any error (transmission_status is blank). However when I look at the summary report of Service Broker on the sending server under #Messages in Transmission Queue it shows 2 messages and “MyInitiatorService(Non existent service)” in the key to the graph. If there was a problem with the service why would it not show the error in the transmission queue, and what is the problem with the service?

|||I don't know what routing article you mention, but you should definitely have a route both on the sending side as well as on the receiving side - in the databases, not in MSDB.

Also, take out the END CONVERSATION after you have send. End conversation kills the conversation and discards un-send messages. That's probably why you don't see a message in the sys.transmission_queue.

Niels|||

Most likely your message reaches the target, it gets denied access on the service (since you use unsecure dialogs and you don't grant SEND permission to [Public]), the error comes back and then the dialog gets deleted, since you already ended it.

1. Grant SEND permission to [Public] on the target service
2. Don't end the dialog on the initiator side prematurely

HTH,
~ Remus

|||

BTW, you could try following the steps from this article to identify the problem: http://blogs.msdn.com/remusrusanu/archive/2005/12/20/506221.aspx

HTH,
~ Remus

|||

Niels, End conversation does not discard pending messages. However, once you have closed the conversation on your end, you will no longer be able to receive response messages, including errors sent back by target (eg> sender does not have permission to send to this target service).

Flamin, therefore you should not end conversation at the initiator until you've confirmed that it has been delivered to the target service.

Rushi

|||

Thanks for the clarification on End Conversation, I didn’t know that ending the conversation would block errors too. As soon as I removed the End Conversation I received a permissions error. As you suspected Remus the problem was due to a lack of send permissions on the service.

|||

Hi Remus,

I am facing problem which is somewhat related to this it will be great if you can help me in resolving it. Actually for me every thing is working fine in the sense i am able to send and receive the messages.

But i see their are so many messages which are stuck up in sys.conversation_endpoints table. All this messages are having state as DI and initiator as 0.

As i am sending number of messages using same queue i am not able to get to the route of the cause due to which messages are getting stuck up.

Even i am ending conversation on initiator end so can that be the reason for the issue.

Please let me know if you need any more information from me.

Thanks

|||

Those are not messages, but conversation endpoints. DI state for is_initiator = 0 means that you receive EndDialog message on the target, but you don't end the target endpoint of the dialog. To completely close, a conversation must be ended by both conversation endpoints (initiator and target). Typicaly this means than wehn the RECEIVE returns a message of type [http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog] you should issue END CONVERSATION on the received handle.

HTH,
~ Remus

|||

Thanks for your suggestions

But the real issue is when and how should i delete those records from target end.

This is how i am sending message

SELECT @.SendService = '//'+@.Pod_ID+'/TransactionQueue',
@.ReceiveService = '//ODS/'+@.Pod_ID+'/TransactionQueue',
@.Contract = '//Contract/TransactionQueue';

BEGIN DIALOG CONVERSATION @.handle
FROM SERVICE @.SendService
TO SERVICE @.ReceiveService
ON CONTRACT @.Contract;

SEND ON CONVERSATION @.handle
MESSAGE TYPE @.xmlMessageType(@.xmlMessage);

END CONVERSATION @.handle;

And this is how i am processing the message on target end

RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;

I am having a code

IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
RETURN 0
END

Which i thought is creating problem. But i see their are no records with this message type in TransactionQueue (user defined queue) and sys.transmission_queue (system queue).

I am still curious to know how can i get rid of those records from conversation_endpoints. As the count is growing like anything.

Just one more question. If solution is ending conversation on target end, which approach should i follow

1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

2: IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

TIA

Prashant

|||

In case 1, you are ending the dialog regardless of the type of message received. If you expect more than one message interaction, there will be no way to receive more messages.

In case 2, you are ending the dialog only when the initiator has closed the dialog and you know for sure, no more messages are expected.

Also, let me warn you that the pattern you are using (which we call fire-and-forget), where the initiator begins a dialog, sends a message and ends the conversation can be problematic for two main reasons:

i) There is no app-level reliability, i.e. without getting a response back, the initiating app will never know whether its message was processed or not.

ii) During development, you will not be able to see error messages sent back by the target.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.

|||

Prashant wrote:


1: RECEIVE TOP(1) @.xmlMessage = message_body,
@.handle = conversation_handle,
@.message_type = message_type_name
FROM TransactionQueue;
END CONVERSATION @.handle;

Here you are ending the dialog regardless of the type of message being received. If you expect more than a single message to be received on the same dialog, this would be incorrect.

Prashant wrote:


IF @.message_type = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @.handle;
RETURN 0
END

Here you expect the initiator to close the dialog first and then the target closes the dialog upon receiving the end-dialog message. This seems more appropriate if you will have multiple messages on the dialog and the initiator decides when it is done sending messages. Remember, when the initiator ends a dialog, there is no way for it to know if its last message was processed or not.