Mars(multiple active resultset) : Disadvantages?

Question

Does any one know what are the Disadvantages of Mars(multiple active resultset)? i.e does any one know any reason which should make one avoid to use MARS e.g. there are cases where cursors are more useful then MARS.

Answer 1

depending on what? there are no real disadvantages.

they don't support Transaction savepoints. but i don't think of this as a disadvantage.

Answer 2

• It takes slightly more server resources than doing one connection at a time.
• I believe if you want to integrate transactions between the connections, you can't use a plain vanilla SqlTransaction on your client end -- you'll have to use a distributed transaction (can anyone verify this?)
• You have to be running SQL Server 2005 or later. So that can be a problem in legacy (ack!) environments.

Answer 3

There are apparently at least two known (potential) drawbacks (from this (1) Team blog):

1. Obviously this can cause potential problems for any legacy systems which weren't designed to run against a MARS enabled design - "existing code optimized to run in the non-MARS world may show a slight performance dip when run un-modified with MARS"

2. “With MARS you can send multiple multi-statement batches to the server. The server will interleave execution of such batches, which means that if the batches change server state via SET or USE statements, for example, or use TSQL transaction management statements (BEGIN TRAN, COMMIT, ROLLBACK), both you and the server can get confused about what your actual intent is.”

I've yet to try out a MARS enabled design, but I'm coming very close to doing so on my current project. We have a slight issue with competing (and sometimes dependant) query operations (like lazy loading configuration data out of the same database that an active recordset is executing).

There's more information on the MSDN site (2) here

[ (1) http://blogs.msdn.com/sqlnativeclient/archive/2006/09/27/774290.aspx ]
[ (2) http://msdn.microsoft.com/en-us/library/ms131686.aspx ]