[RESOLVED] Load Event Aborting

[silverblatt]

Thanks for the additional information, Shaggy Hiker. I get that there is a cost to leaving a connection open (versus closing it immediately after each operation that uses it) and that minimizing that cost CAN be an important consideration. However, it's not the only consideration. There's also a cost associated with code that's unnecessarily repetitive and cumbersome - that cost may include increased coding effort and decreased efficiency, especially when reading and maintaining code you haven't looked at in a while, if ever. IMHO, design choices need to be guided by an evaluation of the relative costs and benefits of different approaches, in light of the particular requirements, operating environment, usage patterns and likely maintenance profile of the application. With a relatively few exceptions, I'm very skeptical of rules or design practices which assert that a particular task should ALWAYS be done in a particular way (the exception that does come to mind is that one should always maintain sufficient backups, whatever sufficient means in the particular context).

In this case, I'm re-writing an existing VB6 application. Its database sees very light usage (typically just single CRUD operations) by a handful of users, with even report queries executing quickly, all running on a fast new server. Given that, and the fact that some OTHER programmer will have to maintain the new application after my impending retirement, I'm doing my best to make the code as lean and clean as possible, even if that results in a tiny performance hit that neither the users nor the DBA will ever even notice, let alone care about. Part of my perspective on this question is a huge legacy application I support, with literally hundreds of users pounding on it all day, and various batch processes and report queries running at unpredictable times. That application runs fine, even though each user's main database connection stays open from the time the user launches the application until the time they exit from it.

Of course, if the usage were heavier and/or the queries more demanding, either at present or in the foreseeable future, I'd take a different approach and do what I could to wring every last bit of performance out of the application (including closing connections immediately after every database access), even if that resulted in more bloated code. In the end, I think one needs to choose what's most appropriate to the particular application, rather than blindly following a list of design patterns to the letter in every case.

Thanks for your response.