Nachteile von MARS (Multiple Active Result Sets)?

Kennt jemand irgendwelche Nachteile von MARS (Multiple Active Result Sets)? Kennt jemand einen Grund, warum man MARS vermeiden sollte, wie in Fällen, in denen Cursor nützlicher sind als MARS.

Es gibt anscheinend mindestens zwei bekannte (potenzielle) Nachteile (aus diesem (1) Team-Blog ):

1. Offensichtlich kann dies potenzielle Probleme für Legacy-Systeme verursachen, die nicht für die Ausführung mit einem MARS-fähigen Design ausgelegt sind. "Vorhandener Code, der für die Ausführung in der Nicht-MARS-Welt optimiert wurde, kann einen leichten Leistungsabfall aufweisen, wenn er ohne Modifikation mit MARS ausgeführt wird."

2. „Mit MARS können Sie mehrere Stapel mit mehreren Anweisungen an den Server senden. Der Server verschachtelt die Ausführung solcher Stapel. Dies bedeutet, dass sowohl Sie als auch der Server verwirrt werden können, wenn die Stapel den Serverstatus beispielsweise über SET- oder USE-Anweisungen ändern oder TSQL-Transaktionsverwaltungsanweisungen (BEGIN TRAN, COMMIT, ROLLBACK) verwenden darüber, was deine eigentliche Absicht ist. "

Ich habe noch kein MARS-fähiges Design ausprobiert, aber ich komme meinem aktuellen Projekt sehr nahe. Wir haben ein kleines Problem mit konkurrierenden (und manchmal abhängigen) Abfragevorgängen (z. B. verzögertes Laden von Konfigurationsdaten aus derselben Datenbank, die ein aktives Recordset ausführt).

Weitere Informationen zur MSDN-Site (2) finden Sie hier

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

• Es sind etwas mehr Serverressourcen erforderlich, als jeweils eine Verbindung herzustellen.
• Sie müssen SQL Server 2005 oder höher ausführen. Dies kann in älteren Umgebungen (ack!) Ein Problem sein.

je nachdem was? Es gibt keine wirklichen Nachteile.

Sie unterstützen keine Transaktionssicherungspunkte. aber ich halte das nicht für einen nachteil.