Es gibt anscheinend mindestens zwei bekannte (potenzielle) Nachteile (davon (1) Teamblog ):
-
Offensichtlich kann dies zu potenziellen Problemen für Legacy-Systeme führen, die nicht für die Ausführung mit einem MARS-fähigen Design entwickelt wurden - "vorhandener Code, der für die Ausführung in der Nicht-MARS-Welt optimiert ist, kann einen leichten Leistungseinbruch aufweisen, wenn er unmodifiziert ausgeführt wird MARS"
-
„Mit MARS können Sie mehrere Batches mit mehreren Anweisungen an den Server senden. Der Server wird die Ausführung solcher Stapel verschachteln, was bedeutet, dass, wenn die Stapel den Serverstatus beispielsweise über SET- oder USE-Anweisungen ändern oder TSQL-Anweisungen zur Transaktionsverwaltung (BEGIN TRAN, COMMIT, ROLLBACK) verwenden, sowohl Sie als auch der Server verwirrt werden können darüber, was Ihre eigentliche Absicht ist.“
Ich muss noch ein MARS-fähiges Design ausprobieren, aber ich komme dem bei meinem aktuellen Projekt sehr nahe. Wir haben ein kleines Problem mit konkurrierenden (und manchmal abhängigen) Abfrageoperationen (wie verzögertes Laden von Konfigurationsdaten aus derselben Datenbank, die ein aktives Recordset ausführt).
Weitere Informationen finden Sie auf der MSDN-Website (2) hier
[ (1) https://web.archive.org/web/20190911155929/https://blogs.msdn.microsoft.com/sqlnativeclient/2006/09/27/using- mars-mit-sql-nativem-client/
]
[ (2) http://msdn.microsoft. com/en-us/library/ms131686.aspx
]
