Apparentemente ci sono almeno due (potenziali) svantaggi noti (da questo (1) Blog del team ):
-
Ovviamente questo può causare potenziali problemi per tutti i sistemi legacy che non sono stati progettati per funzionare con un design abilitato per MARS - "il codice esistente ottimizzato per essere eseguito nel mondo non MARS può mostrare un leggero calo delle prestazioni se eseguito senza modifiche con MARTE"
-
"Con MARS puoi inviare più batch di istruzioni multiple al server. Il server interromperà l'esecuzione di tali batch, il che significa che se i batch cambiano lo stato del server tramite le istruzioni SET o USE, ad esempio, o utilizzano istruzioni di gestione delle transazioni TSQL (BEGIN TRAN, COMMIT, ROLLBACK), sia tu che il server potete confondervi su quale sia il tuo reale intento."
Devo ancora provare un design abilitato a MARS, ma mi sto avvicinando molto a farlo sul mio attuale progetto. Abbiamo un piccolo problema con le operazioni di query concorrenti (e talvolta dipendenti) (come il caricamento lento dei dati di configurazione dallo stesso database che sta eseguendo un recordset attivo).
Sono disponibili ulteriori informazioni sul sito MSDN (2) qui
[ (1) https://web.archive.org/web/20190911155929/https://blogs.msdn.microsoft.com/sqlnativeclient/2006/09/27/using- mars-con-sql-client-nativo/
]
[ (2) http://msdn.microsoft. com/en-us/library/ms131686.aspx
]
