Does close connection work placed after redirect?

[Marshall]

All,

I have a question about closeting a connection. If you put the
"connection.Close" statement on a line below a redirect does it ever run?
See example below.

Thanks in advance for your help, Marshall.

<%
Dim cnxONE

'Connect DB
Set cnxONE = Server.CreateObject("ADODB.Connection")
cnxONE.open
"NAME",Application("RuntimeUserName"),Application( "RuntimePassword")

'Do some ADO stuff here
'
'
If ['ADO stuff worked ok] Then
Response.Redirect "/Somepage.asp"
End If

'Do some other ADO stuff here
If ['other ADO stuff worked ok] Then
Response.Redirect "/SomeOtherPage.asp"
End If

'QUESTION???
'Does the next "close" line ever get run - since the page was redirected
above ????
cnxONE.Close

%>

[Mark Schupp]

The connection should be closed when the connection object goes out of scope
and is destroyed (when page processing is complete).

That said, however. It is considered good programming practice to always
close recordsets and connections and to set their variables to Nothing. I
would close any open recordsets and connections before doing a redirect.

--
Mark Schupp
Head of Development
Integrity eLearning
[url]www.ielearning.com[/url]


"Marshall" <nospam@nospam.com> wrote in message
news:esk8g%23NlDHA.2776@tk2msftngp13.phx.gbl...

> All,
>
> I have a question about closeting a connection. If you put the
> "connection.Close" statement on a line below a redirect does it ever run?
> See example below.
>
> Thanks in advance for your help, Marshall.
>
> <%
> Dim cnxONE
>
> 'Connect DB
> Set cnxONE = Server.CreateObject("ADODB.Connection")
> cnxONE.open
> "NAME",Application("RuntimeUserName"),Application( "RuntimePassword")
>
> 'Do some ADO stuff here
> '
> '
> If ['ADO stuff worked ok] Then
> Response.Redirect "/Somepage.asp"
> End If
>
> 'Do some other ADO stuff here
> If ['other ADO stuff worked ok] Then
> Response.Redirect "/SomeOtherPage.asp"
> End If
>
> 'QUESTION???
> 'Does the next "close" line ever get run - since the page was redirected
> above ????
> cnxONE.Close
>
> %>
>
>

[Marshall]

Mark, thanks for the reply,

"Mark Schupp" <mschupp@ielearning.com> wrote in message
news:umdcaEOlDHA.2244@TK2MSFTNGP12.phx.gbl...

> The connection should be closed when the connection object goes out of

scope

> and is destroyed (when page processing is complete).
>
> That said, however. It is considered good programming practice to always
> close recordsets and connections and to set their variables to Nothing. I
> would close any open recordsets and connections before doing a redirect.

The problem with this advice (most books say this also), is that you may
never be able to set the variables to Nothing or close open recordsets
unless you put the close/nothing statements everywhere *before each and
every* redirect statement - and you may have tons of redirects for error
conditions etc. What do you do when you have a redirect within a
DoWhile/MoveNext/Loop construct?

For example:

<%
strGroupsSQL = "SELECT * FROM tblGroups ORDER BY GroupName;"
Set rstGroups = Server.CreateObject("ADODB.Recordset")
rstGroups.Open strGroupsSQL, cnxNAME, 3, 3
If rstGroups.EOF Then
Response.Write "ERROR: Problem with tblGroups!"
Else
do while Not rstGroups.EOF
If [some condition] then
'***** Shouldn't the Close/Nothing go here and also below? *****
Response.Redirect "/Somepage.asp"
End If
rstGroups.MoveNext
loop
End If
rstGroups.Close
set rstGroups = Nothing
%>

I think the basic question is: Do the statements after the redirect perform
any cleanup action if the redirect is taken?

Thanks, Marshall

> --
> Mark Schupp
> Head of Development
> Integrity eLearning
> [url]www.ielearning.com[/url]
>
>
> "Marshall" <nospam@nospam.com> wrote in message
> news:esk8g%23NlDHA.2776@tk2msftngp13.phx.gbl...

> > All,
> >
> > I have a question about closeting a connection. If you put the
> > "connection.Close" statement on a line below a redirect does it ever

run?

> > See example below.
> >
> > Thanks in advance for your help, Marshall.
> >
> > <%
> > Dim cnxONE
> >
> > 'Connect DB
> > Set cnxONE = Server.CreateObject("ADODB.Connection")
> > cnxONE.open
> > "NAME",Application("RuntimeUserName"),Application( "RuntimePassword")
> >
> > 'Do some ADO stuff here
> > '
> > '
> > If ['ADO stuff worked ok] Then
> > Response.Redirect "/Somepage.asp"
> > End If
> >
> > 'Do some other ADO stuff here
> > If ['other ADO stuff worked ok] Then
> > Response.Redirect "/SomeOtherPage.asp"
> > End If
> >
> > 'QUESTION???
> > 'Does the next "close" line ever get run - since the page was

redirected

> > above ????
> > cnxONE.Close
> >
> > %>
> >
> >

>
>

[Bob Barrows]

Marshall wrote:

> Mark, thanks for the reply,
>
> "Mark Schupp" <mschupp@ielearning.com> wrote in message
> news:umdcaEOlDHA.2244@TK2MSFTNGP12.phx.gbl...

>> The connection should be closed when the connection object goes out
>> of scope and is destroyed (when page processing is complete).
>>
>> That said, however. It is considered good programming practice to
>> always close recordsets and connections and to set their variables
>> to Nothing. I would close any open recordsets and connections before
>> doing a redirect.

>
> The problem with this advice (most books say this also), is that you
> may never be able to set the variables to Nothing or close open
> recordsets unless you put the close/nothing statements everywhere
> *before each and every* redirect statement - and you may have tons of
> redirects for error conditions etc. What do you do when you have a
> redirect within a DoWhile/MoveNext/Loop construct?
>

I never redirect within a loop. I always set a boolean variable and exit the
loop when a condition is met that merits a redirect. After the loop, I test
the value of the variable and redirect based on its value. since you say you
could be redirecting to a number of pages, you can assign the url to which
you need to redirect to a string variable, exit the loop (using exit loop -
why loop through the rest of the records unnecessarily), close and destroy
the database objects, then use select case to perform the redirect as
needed.

I also hardly ever loop through recordsets, preferring instead to use
GetRows to stuff the data into an array, close and destroy my database
objects, and loop through the array instead.

>
> I think the basic question is: Do the statements after the redirect
> perform any cleanup action if the redirect is taken?
>

No. A redirect statement redirects. No code after the redirect is executed.

HTH,
Bob Barrows

[Marshall]

Bob,

Yes, redirection within a loop seems bad, and using a var (bool or
otherwise) to flag a condition seems like a better practice.

Fundamental problem is that in the code I am reviewing *every page* has a
header include that does the DB open and a footer include that does the
close. Any redirects within a page will skip the ADO connection close and
possibly a recordset close - as you say - "No code after the redirect is
executed." - so this seems like a bad practice. (It could possibly cause
memory leaks and/or resource hogging.)

Problem is - parameterizing every exit condition and moving ADO connection
open/close statements around every db recordset construct on these ASP pages
seems to create a lot more complexity than simplicity.

From a practical sense is it worth it to add this complexity or just let a
few redirects (without close) occur???

As Mark said "The connection should be closed when the connection object
goes out of scope and is destroyed (when page processing is complete)."
So, there *should* be no harm done.

Thanks for you thoughts, Marshall.


sometimes has 5 or 6 levels of recordset nesting and the bool conditions
would
"Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
news:OG9CwBQlDHA.3688@TK2MSFTNGP11.phx.gbl...

> Marshall wrote:

> > Mark, thanks for the reply,
> >
> > "Mark Schupp" <mschupp@ielearning.com> wrote in message
> > news:umdcaEOlDHA.2244@TK2MSFTNGP12.phx.gbl...

> >> The connection should be closed when the connection object goes out
> >> of scope and is destroyed (when page processing is complete).
> >>
> >> That said, however. It is considered good programming practice to
> >> always close recordsets and connections and to set their variables
> >> to Nothing. I would close any open recordsets and connections before
> >> doing a redirect.

> >
> > The problem with this advice (most books say this also), is that you
> > may never be able to set the variables to Nothing or close open
> > recordsets unless you put the close/nothing statements everywhere
> > *before each and every* redirect statement - and you may have tons of
> > redirects for error conditions etc. What do you do when you have a
> > redirect within a DoWhile/MoveNext/Loop construct?
> >

>
> I never redirect within a loop. I always set a boolean variable and exit

the

> loop when a condition is met that merits a redirect. After the loop, I

test

> the value of the variable and redirect based on its value. since you say

you

> could be redirecting to a number of pages, you can assign the url to which
> you need to redirect to a string variable, exit the loop (using exit

loop -

> why loop through the rest of the records unnecessarily), close and destroy
> the database objects, then use select case to perform the redirect as
> needed.
>
> I also hardly ever loop through recordsets, preferring instead to use
> GetRows to stuff the data into an array, close and destroy my database
> objects, and loop through the array instead.
>

> >
> > I think the basic question is: Do the statements after the redirect
> > perform any cleanup action if the redirect is taken?
> >

> No. A redirect statement redirects. No code after the redirect is

executed.

>
> HTH,
> Bob Barrows
>
>

[Ken Schaefer]

If you have a heap of legacy code, you need to evaluate business costs of
refactoring the code -vs- business benefits.

I would look at reworking the code as/when each page needs to be
upgraded/modified rather than spending a lot of time reworking everything
*unless* the app is currently giving you problems, in which you're going to
have to rework it now!

I would strongly urge you to look at:

a) .getRows() - which is method of the ADO Recordset that moves all the data
from a recordset into a VBScript array (which lets you get rid of the
recordset, and teh underlying connection straight away)

b) developing a function library. That way you don't have to place includes
all over your ASP page. You just put the includes at the top of the page,
and you call routines (functions/subs) in the include files as required
throughout your page.

Then, your pages start to look like:

<%@ Declarations here %>
<%
Option Explicit
%>
<!-- #include files all go here -->
<%
' Dim all your variables here
Dim objConn ' as ADODB.Connection
Dim strSQL ' as String
Dim arrResults ' as String()
Dim strRedirectURL ' as String - where we redirect to

' Open Connection
Set objConn = DBConnOpen(Application("myConnString")

' Get Results
strSQL = "SELECT newURL FROM myTable WHERE URLID = 1"
arrResults = GetArrayFromSQL(objConn, strSQL)

' Dispose of connection
Call objDispose(objConn, True, True)

If isArray(arrResults) then

strRedirectURL = arrResults(0,0)

Else

strRedirectURL = "someDefaultpage.asp"

End If

If not isEmpty(strRedirectURL) then
Response.Redirect(strRedirectURL)
End If
%>
<html>
<head>
<title>An error has occurred!</title>
</head>
<body>
<p>You should not be seeing this</p>
</body>
</html>

Cheers
Ken






"Marshall" <nospam@nospam.com> wrote in message
news:eSmXFYRlDHA.2456@TK2MSFTNGP09.phx.gbl...
: Bob,
:
: Yes, redirection within a loop seems bad, and using a var (bool or
: otherwise) to flag a condition seems like a better practice.
:
: Fundamental problem is that in the code I am reviewing *every page* has a
: header include that does the DB open and a footer include that does the
: close. Any redirects within a page will skip the ADO connection close and
: possibly a recordset close - as you say - "No code after the redirect is
: executed." - so this seems like a bad practice. (It could possibly cause
: memory leaks and/or resource hogging.)
:
: Problem is - parameterizing every exit condition and moving ADO connection
: open/close statements around every db recordset construct on these ASP
pages
: seems to create a lot more complexity than simplicity.
:
: From a practical sense is it worth it to add this complexity or just let a
: few redirects (without close) occur???
:
: As Mark said "The connection should be closed when the connection object
: goes out of scope and is destroyed (when page processing is complete)."
: So, there *should* be no harm done.
:
: Thanks for you thoughts, Marshall.
:
:
: sometimes has 5 or 6 levels of recordset nesting and the bool conditions
: would
: "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
: news:OG9CwBQlDHA.3688@TK2MSFTNGP11.phx.gbl...
: > Marshall wrote:
: > > Mark, thanks for the reply,
: > >
: > > "Mark Schupp" <mschupp@ielearning.com> wrote in message
: > > news:umdcaEOlDHA.2244@TK2MSFTNGP12.phx.gbl...
: > >> The connection should be closed when the connection object goes out
: > >> of scope and is destroyed (when page processing is complete).
: > >>
: > >> That said, however. It is considered good programming practice to
: > >> always close recordsets and connections and to set their variables
: > >> to Nothing. I would close any open recordsets and connections before
: > >> doing a redirect.
: > >
: > > The problem with this advice (most books say this also), is that you
: > > may never be able to set the variables to Nothing or close open
: > > recordsets unless you put the close/nothing statements everywhere
: > > *before each and every* redirect statement - and you may have tons of
: > > redirects for error conditions etc. What do you do when you have a
: > > redirect within a DoWhile/MoveNext/Loop construct?
: > >
: >
: > I never redirect within a loop. I always set a boolean variable and exit
: the
: > loop when a condition is met that merits a redirect. After the loop, I
: test
: > the value of the variable and redirect based on its value. since you say
: you
: > could be redirecting to a number of pages, you can assign the url to
which
: > you need to redirect to a string variable, exit the loop (using exit
: loop -
: > why loop through the rest of the records unnecessarily), close and
destroy
: > the database objects, then use select case to perform the redirect as
: > needed.
: >
: > I also hardly ever loop through recordsets, preferring instead to use
: > GetRows to stuff the data into an array, close and destroy my database
: > objects, and loop through the array instead.
: >
: > >
: > > I think the basic question is: Do the statements after the redirect
: > > perform any cleanup action if the redirect is taken?
: > >
: > No. A redirect statement redirects. No code after the redirect is
: executed.
: >
: > HTH,
: > Bob Barrows
: >
: >
:
:

[Marshall]

Ken,

Thanks for the advice. Your script page construction example looks sound
and simple. And, yes we will need to decide if a page by page fix-up is
possible or a complete rewrite. ASP code can be funny stuff... I am
somewhat new to ASP and I value your advice.

The application I am reviewing uses a similar page construction - with some
differences: @language, options, some common declarations, some global
functions and the *open connection* are contained in a single header
include. The open connection is wrapped in error handling code so it seems
nice to have it run only once in the header include page.

The relatively small include header file is included on all pages weather it
uses the connection or not. A footer include closes the DB connection -
this small include in included on all pages also. I understand that
connection pooling should make the use of a DB open/close on every page not
significantly effect performance.

A big problem I see in this application is that the connection close is
always at the bottom of a page - and thus never gets run on the pure script
pages. The recordset close are mostly ok since there are few redirects
within the recordset open/close statements.

Looks like adding a few cnxName.Close to this application will help with
some odd active directory (AD) issues - the server sometimes loses
connection with a domain controller. Its possible a memory or resource leak
is responsible for the AD issues cause by not explicitly closing
connections.

Thanks, Marshall.

"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:umVYmgTlDHA.1672@TK2MSFTNGP09.phx.gbl...

> If you have a heap of legacy code, you need to evaluate business costs of
> refactoring the code -vs- business benefits.
>
> I would look at reworking the code as/when each page needs to be
> upgraded/modified rather than spending a lot of time reworking everything
> *unless* the app is currently giving you problems, in which you're going

to

> have to rework it now!
>
> I would strongly urge you to look at:
>
> a) .getRows() - which is method of the ADO Recordset that moves all the

data

> from a recordset into a VBScript array (which lets you get rid of the
> recordset, and teh underlying connection straight away)
>
> b) developing a function library. That way you don't have to place

includes

> all over your ASP page. You just put the includes at the top of the page,
> and you call routines (functions/subs) in the include files as required
> throughout your page.
>
> Then, your pages start to look like:
>
> <%@ Declarations here %>
> <%
> Option Explicit
> %>
> <!-- #include files all go here -->
> <%
> ' Dim all your variables here
> Dim objConn ' as ADODB.Connection
> Dim strSQL ' as String
> Dim arrResults ' as String()
> Dim strRedirectURL ' as String - where we redirect to
>
> ' Open Connection
> Set objConn = DBConnOpen(Application("myConnString")
>
> ' Get Results
> strSQL = "SELECT newURL FROM myTable WHERE URLID = 1"
> arrResults = GetArrayFromSQL(objConn, strSQL)
>
> ' Dispose of connection
> Call objDispose(objConn, True, True)
>
> If isArray(arrResults) then
>
> strRedirectURL = arrResults(0,0)
>
> Else
>
> strRedirectURL = "someDefaultpage.asp"
>
> End If
>
> If not isEmpty(strRedirectURL) then
> Response.Redirect(strRedirectURL)
> End If
> %>
> <html>
> <head>
> <title>An error has occurred!</title>
> </head>
> <body>
> <p>You should not be seeing this</p>
> </body>
> </html>
>
> Cheers
> Ken
>
>
>
>
>
>
> "Marshall" <nospam@nospam.com> wrote in message
> news:eSmXFYRlDHA.2456@TK2MSFTNGP09.phx.gbl...
> : Bob,
> :
> : Yes, redirection within a loop seems bad, and using a var (bool or
> : otherwise) to flag a condition seems like a better practice.
> :
> : Fundamental problem is that in the code I am reviewing *every page* has

a

> : header include that does the DB open and a footer include that does the
> : close. Any redirects within a page will skip the ADO connection close

and

> : possibly a recordset close - as you say - "No code after the redirect is
> : executed." - so this seems like a bad practice. (It could possibly

cause

> : memory leaks and/or resource hogging.)
> :
> : Problem is - parameterizing every exit condition and moving ADO

connection

> : open/close statements around every db recordset construct on these ASP
> pages
> : seems to create a lot more complexity than simplicity.
> :
> : From a practical sense is it worth it to add this complexity or just let

a

> : few redirects (without close) occur???
> :
> : As Mark said "The connection should be closed when the connection object
> : goes out of scope and is destroyed (when page processing is complete)."
> : So, there *should* be no harm done.
> :
> : Thanks for you thoughts, Marshall.
> :
> :
> : sometimes has 5 or 6 levels of recordset nesting and the bool conditions
> : would
> : "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
> : news:OG9CwBQlDHA.3688@TK2MSFTNGP11.phx.gbl...
> : > Marshall wrote:
> : > > Mark, thanks for the reply,
> : > >
> : > > "Mark Schupp" <mschupp@ielearning.com> wrote in message
> : > > news:umdcaEOlDHA.2244@TK2MSFTNGP12.phx.gbl...
> : > >> The connection should be closed when the connection object goes out
> : > >> of scope and is destroyed (when page processing is complete).
> : > >>
> : > >> That said, however. It is considered good programming practice to
> : > >> always close recordsets and connections and to set their variables
> : > >> to Nothing. I would close any open recordsets and connections

before

> : > >> doing a redirect.
> : > >
> : > > The problem with this advice (most books say this also), is that you
> : > > may never be able to set the variables to Nothing or close open
> : > > recordsets unless you put the close/nothing statements everywhere
> : > > *before each and every* redirect statement - and you may have tons

of

> : > > redirects for error conditions etc. What do you do when you have a
> : > > redirect within a DoWhile/MoveNext/Loop construct?
> : > >
> : >
> : > I never redirect within a loop. I always set a boolean variable and

exit

> : the
> : > loop when a condition is met that merits a redirect. After the loop, I
> : test
> : > the value of the variable and redirect based on its value. since you

say

> : you
> : > could be redirecting to a number of pages, you can assign the url to
> which
> : > you need to redirect to a string variable, exit the loop (using exit
> : loop -
> : > why loop through the rest of the records unnecessarily), close and
> destroy
> : > the database objects, then use select case to perform the redirect as
> : > needed.
> : >
> : > I also hardly ever loop through recordsets, preferring instead to use
> : > GetRows to stuff the data into an array, close and destroy my database
> : > objects, and loop through the array instead.
> : >
> : > >
> : > > I think the basic question is: Do the statements after the redirect
> : > > perform any cleanup action if the redirect is taken?
> : > >
> : > No. A redirect statement redirects. No code after the redirect is
> : executed.
> : >
> : > HTH,
> : > Bob Barrows
> : >
> : >
> :
> :
>
>

[Ken Schaefer]

The problem with structuring your site like this means that:
a) your connection is open for the entire page
-and-
b) your connection is open regardless of whether you need it or not

When the connection is open, it is removed from the pool (and unavailable to
other pages).

Personally, I think that a system where you include a routine that opens the
connection is more flexible, since the routine is not automatically called.
You do, however, need an extra line in your page where you do want to open
the connection. However, one extra line isn't going to hurt.

Now, suppose you decide you need a new database for this application (or, it
needs to tie into a second database, say, due to a company merger). Are you
going to open two connections (one to each database) in your include? Even
if you don't need one, or either, of the connections? See how this starts to
become a problem?

Cheers
Ken

"Marshall" <nospam@nospam.com> wrote in message
news:uU8IvkVlDHA.2140@TK2MSFTNGP09.phx.gbl...
: Ken,
:
: Thanks for the advice. Your script page construction example looks sound
: and simple. And, yes we will need to decide if a page by page fix-up is
: possible or a complete rewrite. ASP code can be funny stuff... I am
: somewhat new to ASP and I value your advice.
:
: The application I am reviewing uses a similar page construction - with
some
: differences: @language, options, some common declarations, some global
: functions and the *open connection* are contained in a single header
: include. The open connection is wrapped in error handling code so it
seems
: nice to have it run only once in the header include page.
:
: The relatively small include header file is included on all pages weather
it
: uses the connection or not. A footer include closes the DB connection -
: this small include in included on all pages also. I understand that
: connection pooling should make the use of a DB open/close on every page
not
: significantly effect performance.
:
: A big problem I see in this application is that the connection close is
: always at the bottom of a page - and thus never gets run on the pure
script
: pages. The recordset close are mostly ok since there are few redirects
: within the recordset open/close statements.
:
: Looks like adding a few cnxName.Close to this application will help with
: some odd active directory (AD) issues - the server sometimes loses
: connection with a domain controller. Its possible a memory or resource
leak
: is responsible for the AD issues cause by not explicitly closing
: connections.
:
: Thanks, Marshall.
:
: "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
: news:umVYmgTlDHA.1672@TK2MSFTNGP09.phx.gbl...
: > If you have a heap of legacy code, you need to evaluate business costs
of
: > refactoring the code -vs- business benefits.
: >
: > I would look at reworking the code as/when each page needs to be
: > upgraded/modified rather than spending a lot of time reworking
everything
: > *unless* the app is currently giving you problems, in which you're going
: to
: > have to rework it now!
: >
: > I would strongly urge you to look at:
: >
: > a) .getRows() - which is method of the ADO Recordset that moves all the
: data
: > from a recordset into a VBScript array (which lets you get rid of the
: > recordset, and teh underlying connection straight away)
: >
: > b) developing a function library. That way you don't have to place
: includes
: > all over your ASP page. You just put the includes at the top of the
page,
: > and you call routines (functions/subs) in the include files as required
: > throughout your page.
: >
: > Then, your pages start to look like:
: >
: > <%@ Declarations here %>
: > <%
: > Option Explicit
: > %>
: > <!-- #include files all go here -->
: > <%
: > ' Dim all your variables here
: > Dim objConn ' as ADODB.Connection
: > Dim strSQL ' as String
: > Dim arrResults ' as String()
: > Dim strRedirectURL ' as String - where we redirect to
: >
: > ' Open Connection
: > Set objConn = DBConnOpen(Application("myConnString")
: >
: > ' Get Results
: > strSQL = "SELECT newURL FROM myTable WHERE URLID = 1"
: > arrResults = GetArrayFromSQL(objConn, strSQL)
: >
: > ' Dispose of connection
: > Call objDispose(objConn, True, True)
: >
: > If isArray(arrResults) then
: >
: > strRedirectURL = arrResults(0,0)
: >
: > Else
: >
: > strRedirectURL = "someDefaultpage.asp"
: >
: > End If
: >
: > If not isEmpty(strRedirectURL) then
: > Response.Redirect(strRedirectURL)
: > End If
: > %>
: > <html>
: > <head>
: > <title>An error has occurred!</title>
: > </head>
: > <body>
: > <p>You should not be seeing this</p>
: > </body>
: > </html>
: >
: > Cheers
: > Ken
: >
: >
: >
: >
: >
: >
: > "Marshall" <nospam@nospam.com> wrote in message
: > news:eSmXFYRlDHA.2456@TK2MSFTNGP09.phx.gbl...
: > : Bob,
: > :
: > : Yes, redirection within a loop seems bad, and using a var (bool or
: > : otherwise) to flag a condition seems like a better practice.
: > :
: > : Fundamental problem is that in the code I am reviewing *every page*
has
: a
: > : header include that does the DB open and a footer include that does
the
: > : close. Any redirects within a page will skip the ADO connection close
: and
: > : possibly a recordset close - as you say - "No code after the redirect
is
: > : executed." - so this seems like a bad practice. (It could possibly
: cause
: > : memory leaks and/or resource hogging.)
: > :
: > : Problem is - parameterizing every exit condition and moving ADO
: connection
: > : open/close statements around every db recordset construct on these ASP
: > pages
: > : seems to create a lot more complexity than simplicity.
: > :
: > : From a practical sense is it worth it to add this complexity or just
let
: a
: > : few redirects (without close) occur???
: > :
: > : As Mark said "The connection should be closed when the connection
object
: > : goes out of scope and is destroyed (when page processing is
complete)."
: > : So, there *should* be no harm done.
: > :
: > : Thanks for you thoughts, Marshall.
: > :
: > :
: > : sometimes has 5 or 6 levels of recordset nesting and the bool
conditions
: > : would
: > : "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
: > : news:OG9CwBQlDHA.3688@TK2MSFTNGP11.phx.gbl...
: > : > Marshall wrote:
: > : > > Mark, thanks for the reply,
: > : > >
: > : > > "Mark Schupp" <mschupp@ielearning.com> wrote in message
: > : > > news:umdcaEOlDHA.2244@TK2MSFTNGP12.phx.gbl...
: > : > >> The connection should be closed when the connection object goes
out
: > : > >> of scope and is destroyed (when page processing is complete).
: > : > >>
: > : > >> That said, however. It is considered good programming practice to
: > : > >> always close recordsets and connections and to set their
variables
: > : > >> to Nothing. I would close any open recordsets and connections
: before
: > : > >> doing a redirect.
: > : > >
: > : > > The problem with this advice (most books say this also), is that
you
: > : > > may never be able to set the variables to Nothing or close open
: > : > > recordsets unless you put the close/nothing statements everywhere
: > : > > *before each and every* redirect statement - and you may have tons
: of
: > : > > redirects for error conditions etc. What do you do when you have
a
: > : > > redirect within a DoWhile/MoveNext/Loop construct?
: > : > >
: > : >
: > : > I never redirect within a loop. I always set a boolean variable and
: exit
: > : the
: > : > loop when a condition is met that merits a redirect. After the loop,
I
: > : test
: > : > the value of the variable and redirect based on its value. since you
: say
: > : you
: > : > could be redirecting to a number of pages, you can assign the url to
: > which
: > : > you need to redirect to a string variable, exit the loop (using exit
: > : loop -
: > : > why loop through the rest of the records unnecessarily), close and
: > destroy
: > : > the database objects, then use select case to perform the redirect
as
: > : > needed.
: > : >
: > : > I also hardly ever loop through recordsets, preferring instead to
use
: > : > GetRows to stuff the data into an array, close and destroy my
database
: > : > objects, and loop through the array instead.
: > : >
: > : > >
: > : > > I think the basic question is: Do the statements after the
redirect
: > : > > perform any cleanup action if the redirect is taken?
: > : > >
: > : > No. A redirect statement redirects. No code after the redirect is
: > : executed.
: > : >
: > : > HTH,
: > : > Bob Barrows
: > : >
: > : >
: > :
: > :
: >
: >
:
:

[Bob Barrows]

Marshall wrote:

>
> From a practical sense is it worth it to add this complexity or just
> let a few redirects (without close) occur???
>

It depends on if your webserver is experiencing any otherwise inexplicable
problems. There have been many incidents reported in these newsgroups where
IIS would simply stop serving ASP pages after a few days of continuous use,
requiring a reboot. These problems have been usually solved by advising the
victims to add code to explicitly close and destroy their ADO objects.

Objects are "supposed" to be automatically cleaned up when they go out of
scope. However, with ADO objects, there are situations where the objects
cannot be implicitly closed due to the state they may be in when they go out
of scope. I don't have access to the reference from which I learned this at
the moment so I can't provide any details (which means I did not
sufficiently learn it, I guess <grin> - I'm going to have to go back and
reread that next week). Anyways, this is the cause of the memory leaks.

So, if you're not having any problems, you may be able to get away without a
lot of rewrites. If your server is exhibiting the memory-leak symptoms, then
you're going to have to bite the bullet.

In either case, the lessons learned here should be applied to all future
code, correct?

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often

[Marshall]

Bob, Ken,

Yes, after reading your advice and reading some articles on the issues and
how connection pooling works I am certain that the connection open/close
should be removed from the header/footer includes and targeted to exactly
and only where its needed - but this means that we will need to touch every
page since every page uses the header file - arrgh....

Well at least this is a vote in favor of a full rewrite...

Thanks, Marshall

"Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
news:eV2GN%23WlDHA.2424@TK2MSFTNGP10.phx.gbl...

> Marshall wrote:

> >
> > From a practical sense is it worth it to add this complexity or just
> > let a few redirects (without close) occur???
> >

>
> It depends on if your webserver is experiencing any otherwise inexplicable
> problems. There have been many incidents reported in these newsgroups

where

> IIS would simply stop serving ASP pages after a few days of continuous

use,

> requiring a reboot. These problems have been usually solved by advising

the

> victims to add code to explicitly close and destroy their ADO objects.
>
> Objects are "supposed" to be automatically cleaned up when they go out of
> scope. However, with ADO objects, there are situations where the objects
> cannot be implicitly closed due to the state they may be in when they go

out

> of scope. I don't have access to the reference from which I learned this

at

> the moment so I can't provide any details (which means I did not
> sufficiently learn it, I guess <grin> - I'm going to have to go back and
> reread that next week). Anyways, this is the cause of the memory leaks.
>
> So, if you're not having any problems, you may be able to get away without

a

> lot of rewrites. If your server is exhibiting the memory-leak symptoms,

then

> you're going to have to bite the bullet.
>
> In either case, the lessons learned here should be applied to all future
> code, correct?
>
> --
> Microsoft MVP - ASP/ASP.NET
> Please reply to the newsgroup. This email account is my spam trap so I
> don't check it very often
>
>

[Ken Schaefer]

That would be the prefered way of doing it. However, we all have other
business constraints. If the application isn't giving you problems at the
moment, I'd only start rewriting individual pages when they needed to be
changed. That way, it isn't going to cost your organisation a boat-load of
developer time rewriting things that may not be optimal, but may keep
working fine anyway.

Cheers
Ken

"Marshall" <nospam@nospam.com> wrote in message
news:%23D1nlaalDHA.2424@TK2MSFTNGP10.phx.gbl...
: Bob, Ken,
:
: Yes, after reading your advice and reading some articles on the issues and
: how connection pooling works I am certain that the connection open/close
: should be removed from the header/footer includes and targeted to exactly
: and only where its needed - but this means that we will need to touch
every
: page since every page uses the header file - arrgh....
:
: Well at least this is a vote in favor of a full rewrite...
:
: Thanks, Marshall
:
: "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
: news:eV2GN%23WlDHA.2424@TK2MSFTNGP10.phx.gbl...
: > Marshall wrote:
: > >
: > > From a practical sense is it worth it to add this complexity or just
: > > let a few redirects (without close) occur???
: > >
: >
: > It depends on if your webserver is experiencing any otherwise
inexplicable
: > problems. There have been many incidents reported in these newsgroups
: where
: > IIS would simply stop serving ASP pages after a few days of continuous
: use,
: > requiring a reboot. These problems have been usually solved by advising
: the
: > victims to add code to explicitly close and destroy their ADO objects.
: >
: > Objects are "supposed" to be automatically cleaned up when they go out
of
: > scope. However, with ADO objects, there are situations where the objects
: > cannot be implicitly closed due to the state they may be in when they go
: out
: > of scope. I don't have access to the reference from which I learned this
: at
: > the moment so I can't provide any details (which means I did not
: > sufficiently learn it, I guess <grin> - I'm going to have to go back and
: > reread that next week). Anyways, this is the cause of the memory leaks.
: >
: > So, if you're not having any problems, you may be able to get away
without
: a
: > lot of rewrites. If your server is exhibiting the memory-leak symptoms,
: then
: > you're going to have to bite the bullet.
: >
: > In either case, the lessons learned here should be applied to all future
: > code, correct?
: >
: > --
: > Microsoft MVP - ASP/ASP.NET
: > Please reply to the newsgroup. This email account is my spam trap so I
: > don't check it very often
: >
: >
:
: