Er zijn blijkbaar ten minste twee bekende (potentiële) nadelen (van deze (1) Teamblog ):
-
Uiteraard kan dit potentiële problemen veroorzaken voor alle legacy-systemen die niet zijn ontworpen om te draaien tegen een MARS-enabled ontwerp - "bestaande code die is geoptimaliseerd om te worden uitgevoerd in de niet-MARS-wereld kan een lichte prestatiedaling vertonen wanneer deze niet wordt gemodificeerd met MARS"
-
“Met MARS kun je meerdere batches met meerdere verklaringen naar de server sturen. De server zal de uitvoering van dergelijke batches interleaven, wat betekent dat als de batches de serverstatus wijzigen via bijvoorbeeld SET- of USE-instructies of TSQL-transactiebeheerinstructies gebruiken (BEGIN TRAN, COMMIT, ROLLBACK), zowel u als de server in de war kunnen raken over wat uw werkelijke bedoeling is.”
Ik moet nog een MARS-enabled ontwerp uitproberen, maar ik kom er heel dicht bij om dit te doen voor mijn huidige project. We hebben een klein probleem met concurrerende (en soms afhankelijke) querybewerkingen (zoals lui laden van configuratiegegevens uit dezelfde database die een actieve recordset uitvoert).
Er is meer informatie op de MSDN-site (2) hier
[ (1) https://web.archive.org/web/20190911155929/https://blogs.msdn.microsoft.com/sqlnativeclient/2006/09/27/using- mars-with-sql-native-client/
]
[ (2) http://msdn.microsoft. com/en-us/library/ms131686.aspx
]