Included function not always found.

[Roland Hall]

in message
: Roland Hall wrote:
: > Why is this:
: >
: > SET ExecuteSQL=RS
: >
: > instead of just:
: >
: > ExecuteSQL=RS
:
: Ummmm ... because RS is an object, not a scalar variable? And he's
: attempting to return the RS object to caller?

Are you answering my question with a question? two actually? (O:=

 

[Bob Barrows [MVP]]

in message


Are you answering my question with a question? two actually? (O:=

Why do you say that?

Bob Barrows

 

[TomB]

Thanks Aaron and others.

I honestly thought this was the better way to go. I thought that using
disconnected recordsets, would be more efficient.

I do (usually) only call my function once on a page. But, you are right
there are times I don't.

My other goal with this function was that it was in one spot, which offered
me the option of maintaining only one piece of database code.

I gather, Aaron that you'd recommend opening a connection at the top of a
page, and closing it at the end? Assuming of course that you actually need
a connection on the page. What about the recordsets? Do you close and
discard them as soon as possible, or just re-use as needed?

Roland... In asp you have to SET an object, while in .Net you don't
(actually I think you can't). I'm guessing that's where the confusion lie.

 

[Bob Barrows [MVP]]

Thanks Aaron and others.

I honestly thought this was the better way to go. I thought that
using disconnected recordsets, would be more efficient.

I have used disconnected recordsets, when I've needed to use Filter, Find or
Sort functionality (or any other functionality provided by a recordset
object that can't be achieved in a string or an array). Otherwise, it's
either GetRows or GetString immediately after opening the recordset,
followed by Close.

I do (usually) only call my function once on a page. But, you are
right there are times I don't.

My other goal with this function was that it was in one spot, which
offered me the option of maintaining only one piece of database code.

I gather, Aaron that you'd recommend opening a connection at the top
of a page, and closing it at the end?

That's how all my pages work.

Assuming of course that you
actually need a connection on the page. What about the recordsets?
Do you close

Yes. My normal procedure is to dump the data into an array or string as
soon as possible and close the recordset.

and discard them as soon as possible,

I normally discard/destroy them as soon as I am sure I will not use them
anymore.

Bob Barrows

 

[TomB]

Thanks Bob.

I have used disconnected recordsets, when I've needed to use Filter, Find or
Sort functionality (or any other functionality provided by a recordset
object that can't be achieved in a string or an array). Otherwise, it's
either GetRows or GetString immediately after opening the recordset,
followed by Close.


That's how all my pages work.


Yes. My normal procedure is to dump the data into an array or string as
soon as possible and close the recordset.

I normally discard/destroy them as soon as I am sure I will not use them
anymore.

Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

 

[Patrice]

Yes, IMO it doesn't defeat that much connection pooling. My understanding is
that :
- you'll get at the pool 5 times to get a connection
- you still benefit IMO from connection poolling in particular you still
have a single connection open at any one time not using up to 5 connections
and even more importantly as they are returned to the pool, another page
served to another user will be able to reuse the connection(s) you used

IMO you just loose the time needed to get/release 5 connection from/to the
pool but you still benefit from the pool...

Patrice

 

[Aaron Bertrand - MVP]

I've only recently started to use getRows() more, but other than that, I
follow pretty much the same practice as Bob.

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/