Istnieją najwyraźniej co najmniej dwie znane (potencjalne) wady (z tego (1) Blog zespołu ):
-
Oczywiście może to powodować potencjalne problemy w przypadku wszelkich starszych systemów, które nie zostały zaprojektowane do pracy z projektem obsługującym MARS - "istniejący kod zoptymalizowany do działania w świecie innym niż MARS może wykazywać niewielki spadek wydajności, gdy jest uruchamiany bez modyfikacji za pomocą MARS"
-
„Dzięki MARS możesz wysłać wiele wielowyrazowych partii na serwer. Serwer będzie przeplatał wykonywanie takich wsadów, co oznacza, że jeśli wsad zmienią stan serwera za pomocą na przykład instrukcji SET lub USE lub użyją instrukcji zarządzania transakcjami TSQL (BEGIN TRAN, COMMIT, ROLLBACK), zarówno ty, jak i serwer możecie się pomylić o tym, jakie są Twoje rzeczywiste zamiary”.
Jeszcze nie wypróbowałem projektu obsługującego MARS, ale zbliżam się do tego w moim obecnym projekcie. Mamy niewielki problem z konkurencyjnymi (a czasami zależnymi) operacjami zapytań (np. leniwe ładowanie danych konfiguracyjnych z tej samej bazy danych, którą wykonuje aktywny zestaw rekordów).
Więcej informacji znajdziesz w witrynie MSDN (2) tutaj
[ (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
]
