Best Practice

[Wayne Wengert]

I am creating an aspx process to read rows from a table, display specific
fields, wait for the administrator (the only user of this process) to decide
what action to take based on the data and then delete the row and move on to
the next one. Each row in that table represents a request by a user for a
change to their subscription status (change address, new request, delete
etc.). The administrator usually takes less than a minute to decide whether
to accept the request or to reject it (we are trying to prevent someone for
entering bogus information, profanity, etc.)

Is it best to keep the connection open during the process of stepping
through the rows or to "open - display the data - close" and wait for the
administrator to decide the action to be taken and then re-open the
connection, delete the row just processed and then deal with the next row?
It seems like a lot of open/retrieve/close (there are usually a couple of
hundred rows to process)

Any suggestions appreciated.

Wayne

 

[Dave Fancher]

If I understand you correctly you have described the following scenario:
The administrator loads a page that displays a single request and takes an
action on it. When the form posts back, the next request is displayed, and
so on.

How about having a page that displays all of the requests with a mechanism
for taking the appropriate action for each request and doing all of the
updates/edits/deletes as a batch therefore eliminating many of the HTTP
requests?

The Web is a stateless environment there's no good [effective] way to keep a
connection open between page requests. When the server has finished
building/rendering the page, "everything" associated with the page will go
out of scope. If you leave a connection open when it goes out of scope, you
have [most likely] accomplished nothing more than creating a connection leak
which will gradually kill the performance of your application.

HTH

 

[Steve C. Orr [MVP, MCSD]]

Open and close the connection as often as you want. Don't worry about it.
ADO.NET has built in connection pooling so connections are managed quite
efficiently no matter what you do - unless you hold open connections for
long periods of time.

 

[Wayne Wengert]

Thanks for the advice. I guess I'll do the open/close as suggested. I cant
really create a list for the administrator to work from as there are too
many fields that need to be viewable.

Wayne