Der er tilsyneladende mindst to kendte (potentielle) ulemper (fra denne (1) Teamblog ):
-
Dette kan naturligvis forårsage potentielle problemer for alle ældre systemer, som ikke er designet til at køre mod et MARS-aktiveret design - "eksisterende kode, der er optimeret til at køre i ikke-MARS-verdenen, kan vise et lille ydelsesfald, når det køres uændret med MARS"
-
“Med MARS kan du sende flere batches med flere erklæringer til serveren. Serveren vil interleave eksekvering af sådanne batches, hvilket betyder, at hvis batchene ændrer servertilstand via for eksempel SET- eller USE-sætninger eller bruger TSQL-transaktionsstyringsudsagn (BEGIN TRAN, COMMIT, ROLLBACK), kan både du og serveren blive forvirrede om, hvad din egentlige hensigt er.”
Jeg har endnu ikke prøvet et MARS-aktiveret design, men jeg er meget tæt på at gøre det på mit nuværende projekt. Vi har et lille problem med konkurrerende (og nogle gange afhængige) forespørgselsoperationer (såsom doven indlæsning af konfigurationsdata fra den samme database, som et aktivt postsæt udfører).
Der er flere oplysninger på MSDN-siden (2) her
[ (1) https://web.archive.org/web/20190911155929/https://blogs.msdn.microsoft.com/sqlnativeclient/2006/09/27/using- mars-med-sql-native-client/
]
[ (2) http://msdn.microsoft. com/en-us/library/ms131686.aspx
]