Il y a apparemment au moins deux inconvénients (potentiels) connus (à partir de cela (1) Blog de l'équipe ):
-
Évidemment, cela peut causer des problèmes potentiels pour tous les systèmes hérités qui n'ont pas été conçus pour fonctionner avec une conception compatible MARS - "le code existant optimisé pour fonctionner dans le monde non-MARS peut afficher une légère baisse de performances lorsqu'il est exécuté sans modification avec MARS"
-
"Avec MARS, vous pouvez envoyer plusieurs lots d'instructions multiples au serveur. Le serveur entrelacera l'exécution de ces lots, ce qui signifie que si les lots changent l'état du serveur via des instructions SET ou USE, par exemple, ou utilisent des instructions de gestion des transactions TSQL (BEGIN TRAN, COMMIT, ROLLBACK), vous et le serveur pouvez être confus. quelle est votre intention réelle."
Je n'ai pas encore essayé une conception compatible MARS, mais je suis sur le point de le faire sur mon projet actuel. Nous avons un léger problème avec les opérations de requête concurrentes (et parfois dépendantes) (comme le chargement différé des données de configuration à partir de la même base de données qu'un jeu d'enregistrements actif est en train d'exécuter).
Il y a plus d'informations sur le site MSDN (2) ici
[ (1) https://web.archive.org/web/20190911155929/https://blogs.msdn.microsoft.com/sqlnativeclient/2006/09/27/using- mars-avec-sql-native-client/
]
[ (2) http://msdn.microsoft. com/en-us/library/ms131686.aspx
]
