Connection Resources
-
The main application where I work creates and then destroys a Connection object for every stored procedure that it calls. (SQL Server 2012) Is this unnecessarily wasteful to the point where it might speed things up to reuse open connections? Or do you think it doesn't make much of a difference?
The difficult we do right away... ...the impossible takes slightly longer.
-
The main application where I work creates and then destroys a Connection object for every stored procedure that it calls. (SQL Server 2012) Is this unnecessarily wasteful to the point where it might speed things up to reuse open connections? Or do you think it doesn't make much of a difference?
The difficult we do right away... ...the impossible takes slightly longer.
It's the recommended approach - create the connection as close as possible to where it's needed, and wrap it in a "using" block to make sure it's disposed of as soon as you're done with it. Connection pooling will automatically keep a pool of the low-level connections alive to speed up reconnecting. So long as you're using the same connection string each time, and you dispose of the connection when you're done with it, you shouldn't have any performance issues caused by connecting to SQL. SQL Server Connection Pooling - ADO.NET | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
