An interesting comparison is between clients like Oracle Forms, which connect
for the duration and the .Net client apps which, as you say, generally take
the disconnected approach. This not only means having no persistant db
connection but also things like 'optimisistic locking' where you don't lock
the data you fetch or modify on the client. Instead you check the database at
the point you perform the update/insert/delete to see if anyone else has
changed the data while you've had it in front of you (so to speak) on the
client. Coming from a traditional 'connected' background this does take
getting used to. Something like Oracle Forms will happily stream and cache
millions of rows from a database for you, and lock those you 'touch'.
With web based applications it makes sense to disconnect after each
transaction. The thought of users spread across a network, which could be
global, running an web form application and each one having a persitent
dedicated connection is scary :)
Rob J
"lokee" wrote:
hello all....
i have one query....
can somebody please tell me advantages and disadvantages of making
connection to sql server open at the start of application and closing it at
the end of application (in windows application or web application) ?
what will be consequences ?
is it a good practice ?
please comment.
actually me and my friend is having argument on this...
he says, dot net have disconnected architecture.... so u dont need to every
time (in ur functions or subroutines where u executes different sql commands)
open or close the connection.
well, what is a good practice ?
what exactly is the meaning of disconnected architecture ?
please comment.
