Not directly. You could write a simple job that receives messages from one
system and sends them on the other. Keep in mind that you lose some of the
advantages of Service Broker such as dialogs and no two-phase commit when
you do this. Double queuing a message is usually not very efficient so you
want to look carefully at your scenario to make sure doing this is a better
solution than using MSMQ all the way to the database.

Signature
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
> Hopefully a simple question..
>
[quoted text clipped - 6 lines]
>
> Whats the basic way that it would work?
Thanks for replying.
> Double queuing a message is usually not very efficient so you
> want to look carefully at your scenario to make sure doing this is a better
> solution than using MSMQ all the way to the database.
I don't see how you can use MSMQ all the way to the database? At
some point don't you need an application to read messages from MSMQ
and insert them into the DB, correct?
Here's my scenario.
I have one Windows 2003 Server that is an external semi-public server
that would receive requests from other outside sources over a tcp/ip
based connection.
This Server really has no need for SQL Server 2005, and the costs
inherent with that. Ideally MSMQ would work for that Server.
Then I have another Server that is an internal Server that's highly
protected and isolated, and already uses SQL Server extensively.
This is where SQL Server Service Broker would work nicely to accept
incoming requests, and process them without having to use a custom
application.
The outside server that MSMQ would potentially reside, simply forwards
requests to the internal secure Server that SQL Server resides on.
So given that scenario what would be some potential solutions to make
that work?
On Apr 8, 10:17 am, "Roger Wolter[MSFT]"
<rwol...@online.microsoft.com> wrote:
> Not directly. You could write a simple job that receives messages from one
> system and sends them on the other. Keep in mind that you lose some of the
[quoted text clipped - 19 lines]
>
> - Show quoted text -
Roger Wolter[MSFT] - 10 Apr 2008 06:07 GMT
If you use MSMQ from the front end to the database server, you will need to
have an application running on the database server to receive the MSMQ
messages and pass them into the database. Whether that application puts the
message on a Service Broker queue or does something else in the database
requires a two-phase commit from the MSMQ queue to the database. If I was
doing this, I would put a database on the front end server - maybe SQL
Express to eliminate any expense - and use it to send the messages to the
back end but using MSMQ would also work.

Signature
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Thanks for replying.
> Double queuing a message is usually not very efficient so you
> want to look carefully at your scenario to make sure doing this is a
> better
> solution than using MSMQ all the way to the database.
I don't see how you can use MSMQ all the way to the database? At
some point don't you need an application to read messages from MSMQ
and insert them into the DB, correct?
Here's my scenario.
I have one Windows 2003 Server that is an external semi-public server
that would receive requests from other outside sources over a tcp/ip
based connection.
This Server really has no need for SQL Server 2005, and the costs
inherent with that. Ideally MSMQ would work for that Server.
Then I have another Server that is an internal Server that's highly
protected and isolated, and already uses SQL Server extensively.
This is where SQL Server Service Broker would work nicely to accept
incoming requests, and process them without having to use a custom
application.
The outside server that MSMQ would potentially reside, simply forwards
requests to the internal secure Server that SQL Server resides on.
So given that scenario what would be some potential solutions to make
that work?
On Apr 8, 10:17 am, "Roger Wolter[MSFT]"
<rwol...@online.microsoft.com> wrote:
> Not directly. You could write a simple job that receives messages from one
> system and sends them on the other. Keep in mind that you lose some of the
[quoted text clipped - 26 lines]
>
> - Show quoted text -