Nils Gustav Stråbø (8/22/2010)

---

Ninja's_RGR'us (8/22/2010)

---

Thanks for the link, but just a few quick questions before I spend 2 days reading all those articles :w00t:.

1 - How fast is the response time? I see there's talk about queues, but I can't afford to just sit there and wait for 5 seconds to have my query processed. I've already written the query and it runs in only a few ms and I need to keep it that way (including returning the data).

2 - Can we get the data back as some sort of derived table or does it need to be something like say xml where you need to reparse it before joining to your data?

3 - What's the big safety gain between "sending message" permission VS read only permission on the 1 table where the inventory is saved?

1. The message is queued in the transmission queue should be sent immediately; only restricted by the size of existing pending messages in the transmission queue. Of course there could be a delay if you have 100's of messages put in the message queue at the same time. There will also be a little delay during authentication between the target and destination servers (just saw that I mixed target and destination in my previous post), and depending on the latency between you and your clients this could take a few seconds. But I guess you will have the same issue with linked servers as well. Only way to find out is by testing.

2. No, there is no way to return data that SQL Server interprets as a table. You can return XML, but that has to be parsed, or you can return any text or binary, but that has to be parsed too.

3. None really.

My own experience is that it takes time to get comfortable with Service Broker, especially when dealing with communication between servers. There are a lot of new concepts to get familiar with; transport and dialog security, certificates, keys, endpoints, service bindings, routes, contracts etc. Given that your deadline is 20. September and you have never played with Service Broker before, I would personally not go down that path this time.