Is it bad practice to depend on the .NET automated garbage collector?

Question

It\'s possible to create lots of memory-intensive objects and then abandon references to them. For example, I might want to download and operate on some data from a database

Answer 1

I also agree with Dave's post. You should always dispose and release your database connections, even if the framework you are working has documentation that it is not needed.

As a DBA who has worked with MS SQL, Oracle, Sybase/SAP, and MYSQL, I have been brought in to work on mysterious locking and memory leaking that was blamed on the database when in fact, the issue was because the developer did not close and destroy their connection objects when they were done with them. I've even seen apps that leave idle connections open for days and it can really make things bad when your database is clustered, mirrored, and with Always on recovery groups in SQL Server 2012.

When I took my first .Net class the instructor taught us to only keep database connections open while you are using them. Get in, get your work done and get out. This change has made several systems I have help optimize a lot more reliable. It also frees up connection memory in the RDBMS giving more ram to buffer IO.