December 1, 2008 at 12:01 pm
Building a pretty typical ASP.NET app using Sqlconnections. Is there any reason NOT to use MARS / MultipleActiveResultSets? I'm thinking of having two connection strings: one for regular UI functions that are pretty lightweight sql-wise, and another that uses MARS for web services that make very heavy use of sql. Thoughts?
December 1, 2008 at 12:25 pm
Don't use MARS unless you program for it. If you do not actually program with the events being driven by data being returned to your recordsets, using it will be of little benefit.
For example, in many traditional applications, a developer would execute a stored procedure and then loop through the returned recordset and fill a listbox. This would be a place where MARS will be of no use. Correctly using MARS, you would add code to the recordset events and add each record to the listbox as the record being returned raised the event. In this way, you could have several recordsets with their events being handled at the same time and bind them all to the same connection. Then, if you opened all of the recordsets, they could all stream back data and raise their own events in whatever order the data happened to be returned.
ADO and ADO.Net has supported these types of recordset events for a long time, but most developers (in my experience) seem to have avoided using them and they simply loop through recordsets after they are completely filled. If your programming is going to work like this, don't bother adding the overhead of using MARS to your connections.
December 1, 2008 at 12:45 pm
Good info. Is there any reason to specifically not include the directive for MARS in a connection string? Does it hurt existing code, even if it doesn't benefit it?
December 1, 2008 at 12:49 pm
It adds some overhead - I don't know how much.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply