ADODB Connection Question

[Astra]

Hi All

Just IYHO, which is better:

METHOD 1
=========
Creating the ADODB connection obejct at the beginning of an ASP page in an
include file.

Functions containing the requirement to create any ADODB commands or
recorset ojects to do a query and then close/drop the same objects in an
include file.

Drop/close the ADODB connection obejct at the end of an ASP page in an
include file.

METHOD 2
=========
Encapsulate the ADODB connection within each of the functions so that when
they are executed the connection, retrieval and drop is basically all in
about 3 lines of code.

As far as I can see Method 1 has the bonus of only creating 1 connection
object and then allowing the commands and recordsets to feed off this, but
then again the connection is open for the time it takes the full page to be
generated.

As far as I can see for Method 2 it does keep the connection open to a
minimum, but if I have 3 or 4 queries that need to be run then it means 3 or
4 connections have to be created as well as the commands and recordsets.

I favour Method 1, but what do you think? Is there a Method 3??

Thanks

Robbie

[Bob Barrows]

I usually use the first method, with the modification that I do not open the
connection until just before the first time I need it. IOW, instantiate the
connection and set its connection string in the include file. Then, wait
until the first time you need it to open it. Don't open it then do a lot of
non-database-related activity before using it.

I would only consider the second method if I was doing something for
Amazon.com

Bob Barrows

Astra wrote:

> Hi All
>
> Just IYHO, which is better:
>
> METHOD 1
> =========
> Creating the ADODB connection obejct at the beginning of an ASP page
> in an include file.
>
> Functions containing the requirement to create any ADODB commands or
> recorset ojects to do a query and then close/drop the same objects in
> an include file.
>
> Drop/close the ADODB connection obejct at the end of an ASP page in an
> include file.
>
> METHOD 2
> =========
> Encapsulate the ADODB connection within each of the functions so that
> when they are executed the connection, retrieval and drop is
> basically all in about 3 lines of code.
>
> As far as I can see Method 1 has the bonus of only creating 1
> connection object and then allowing the commands and recordsets to
> feed off this, but then again the connection is open for the time it
> takes the full page to be generated.
>
> As far as I can see for Method 2 it does keep the connection open to a
> minimum, but if I have 3 or 4 queries that need to be run then it
> means 3 or 4 connections have to be created as well as the commands
> and recordsets.
>
> I favour Method 1, but what do you think? Is there a Method 3??
>
> Thanks
>
> Robbie

--
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. If you must reply off-line, then remove the
"NO SPAM"

[J. Baute]

The first is the best imo, because that way you will only be opening 1
connection per page. I have the habbit of passing the ADO connections as a
parameter to objects or functions that need one, instead of having those
create their own every time.

I'd avoid always opening the connection in the include file though, because
in some cases you might not need it at all, in which case setting up a DB
connection is a waste of resources (although with ADO connection pooling
this is probably very minimal).

"Astra" <info@NoEmail.com> wrote in message
news:e$WwVPFKEHA.1388@TK2MSFTNGP09.phx.gbl...

> Hi All
>
> Just IYHO, which is better:
>
> METHOD 1
> =========
> Creating the ADODB connection obejct at the beginning of an ASP page in an
> include file.
>
> Functions containing the requirement to create any ADODB commands or
> recorset ojects to do a query and then close/drop the same objects in an
> include file.
>
> Drop/close the ADODB connection obejct at the end of an ASP page in an
> include file.
>
> METHOD 2
> =========
> Encapsulate the ADODB connection within each of the functions so that when
> they are executed the connection, retrieval and drop is basically all in
> about 3 lines of code.
>
> As far as I can see Method 1 has the bonus of only creating 1 connection
> object and then allowing the commands and recordsets to feed off this, but
> then again the connection is open for the time it takes the full page to

be

> generated.
>
> As far as I can see for Method 2 it does keep the connection open to a
> minimum, but if I have 3 or 4 queries that need to be run then it means 3

or

> 4 connections have to be created as well as the commands and recordsets.
>
> I favour Method 1, but what do you think? Is there a Method 3??
>
> Thanks
>
> Robbie
>
>

[Laphan]

Thanks Guys

J. Baute <WUPYRDEDAWJD@spammotel.com> wrote in message
news:4088ccb7$0$10939$a0ced6e1@news.skynet.be...

The first is the best imo, because that way you will only be opening 1
connection per page. I have the habbit of passing the ADO connections as a
parameter to objects or functions that need one, instead of having those
create their own every time.

I'd avoid always opening the connection in the include file though, because
in some cases you might not need it at all, in which case setting up a DB
connection is a waste of resources (although with ADO connection pooling
this is probably very minimal).

"Astra" <info@NoEmail.com> wrote in message
news:e$WwVPFKEHA.1388@TK2MSFTNGP09.phx.gbl...

> Hi All
>
> Just IYHO, which is better:
>
> METHOD 1
> =========
> Creating the ADODB connection obejct at the beginning of an ASP page in an
> include file.
>
> Functions containing the requirement to create any ADODB commands or
> recorset ojects to do a query and then close/drop the same objects in an
> include file.
>
> Drop/close the ADODB connection obejct at the end of an ASP page in an
> include file.
>
> METHOD 2
> =========
> Encapsulate the ADODB connection within each of the functions so that when
> they are executed the connection, retrieval and drop is basically all in
> about 3 lines of code.
>
> As far as I can see Method 1 has the bonus of only creating 1 connection
> object and then allowing the commands and recordsets to feed off this, but
> then again the connection is open for the time it takes the full page to

be

> generated.
>
> As far as I can see for Method 2 it does keep the connection open to a
> minimum, but if I have 3 or 4 queries that need to be run then it means 3

or

> 4 connections have to be created as well as the commands and recordsets.
>
> I favour Method 1, but what do you think? Is there a Method 3??
>
> Thanks
>
> Robbie
>
>