In my opinion it would depend on usage.
If the app is constantly hitting the database, leave the connection open.
If you are just querying out some stuff in the beginning and not going back to
it regularly, I would close it.
Of course if you want to keep the recordset open, then might need to keep it
open.
Connecting and disconnecting can sometimes take a little while (seconds), but if
it has to be re-established often, then this can annoy the users.
Additionally, depending upon your configuration, your server might have a time
out, and after a period of inactivity it might disconnect you anyway, in which
case you might get a run-time error if you think it should be open. Don't see
this too often with SQL, but pops up with Oracle a lot.
I have apps that use both methods.
Opening and keeping open is the "easy" and sometimes lazy way.
But like I said, the "right" choice depends on what you are doing.
Gerald
"Leo J. Hart IV" <le******@fmr.com> wrote in message
news:b6*************************@posting.google.co m...
Hello,
I come from a mostly web application background, but am currently working on
a desktop app to be designed using VB.NET. The app will have around 15
users; I don't expect that amount to increase significantly.
I'm trying to decide on which approach to use in regards to database
connection handling. Should I open my database connection (to SQL Server)
on application startup and hold it for the user's entire session (meaning
that each user will have 1 dedicated DB connection) or do I go with the
approach I'm more familiar with using on web apps where you open and close
DB connections as you need them.
Most of the guys here are telling me that the first approach is generally
how it's done on client server apps with a small amount of users, but once
again, given my background, I feel a bit uncomfortable with that route.
Any advice from you experience windows programmers out there?
Thanks,
Leo
