Queremos compartirte la mejor respuesta que hemos encontrado online. Deseamos que te sea de ayuda y si quieres comentarnos cualquier detalle que nos pueda ayudar a perfeccionar nuestra información hazlo con libertad.
Solución:
Aparentemente, hay al menos dos inconvenientes conocidos (potenciales) (de este (1) blog del equipo):
-
Obviamente, esto puede causar problemas potenciales para cualquier sistema heredado que no haya sido diseñado para funcionar con un diseño habilitado para MARS: “El código existente optimizado para ejecutarse en el mundo que no es MARS puede mostrar una ligera disminución del rendimiento cuando se ejecuta sin modificar con MARS”
-
“Con MARS puede enviar múltiples lotes de estados de cuenta múltiples al servidor. El servidor intercalará la ejecución de dichos lotes, lo que significa que si los lotes cambian el estado del servidor a través de declaraciones SET o USE, por ejemplo, o usan declaraciones de administración de transacciones TSQL (BEGIN TRAN, COMMIT, ROLLBACK), tanto usted como el servidor pueden confundirse. sobre cuál es tu intención real.”
Todavía tengo que probar un diseño compatible con MARS, pero estoy muy cerca de hacerlo en mi proyecto actual. Tenemos un pequeño problema con las operaciones de consulta que compiten (ya veces son dependientes) (como la carga diferida de datos de configuración de la misma base de datos que está ejecutando un conjunto de registros activo).
Hay más información en el sitio de MSDN (2) aquí
[ (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 ]
- Se necesitan un poco más de recursos del servidor que hacer una conexión a la vez.
- Tiene que estar ejecutando SQL Server 2005 o posterior. Entonces eso puede ser un problema en entornos heredados (¡ack!).
¿dependiendo de qué? no hay desventajas reales.
no admiten puntos de guardado de transacciones. pero no creo que esto sea una desventaja.