Недоліки MARS (кілька наборів активних результатів)?

Хтось знає про будь-які недоліки MARS (Множини активних наборів результатів)? Хто-небудь знає будь-яку причину, чому слід уникати використання MARS, наприклад випадки, коли курсори є більш корисними, ніж MARS.

Очевидно, щонайменше є два відомі (потенційні) недоліки (з цього (1) блогу команди ):

1. Очевидно, це може спричинити потенційні проблеми для будь-якої застарілої системи, яка не була розроблена для роботи з дизайном із підтримкою MARS - "існуючий код, оптимізований для роботи в світі, що не є MARS, може демонструвати незначне зниження продуктивності при запуску без модифікації з MARS"

2. «За допомогою MARS ви можете відправляти кілька пакетів із декількома операторами на сервер. Сервер буде чергувати виконання таких пакетів, це означає, що якщо пакети змінюють стан сервера за допомогою операторів SET або USE, наприклад, або використовують оператори управління транзакціями TSQL (BEGIN TRAN, COMMIT, ROLLBACK), ви і сервер можете заплутатися про те, яким є ваш фактичний намір ".

Я ще не випробував дизайн із підтримкою MARS, але я наближаюся до цього у своєму поточному проекті. У нас є невелика проблема з конкуруючими (а іноді і залежними) операціями запиту (наприклад, ліниве завантаження даних конфігурації з тієї самої бази даних, яку виконує активний набір записів).

Тут є додаткова інформація на сайті MSDN (2)

[(1) http://blogs.msdn.com/sqlnativeclient/archive/2006/09/27/774290.aspx ]
[(2)http://msdn.microsoft.com/en-us/library/ms131686.aspx ]

• Це займає трохи більше ресурсів сервера, ніж одночасне підключення.
• Ви повинні працювати під керуванням SQL Server 2005 або пізнішої версії. Тож це може бути проблемою у застарілих (так!) Середовищах.

залежно від чого? реальних недоліків немає.

вони не підтримують точки збереження транзакцій. але я не вважаю це недоліком.