General question about persistence

[Neil Gould]

Or... when is a script not a script?

I have several modules for managing different aspects of our club's website,
most of which are multi-page.

Does setting such things as server.ScriptTi meout or response.buffer values
at the start of the first page persist throughout the session, or are they
"reset" with each function or sub, etc.?

TIA.

--
Neil Gould
------------------------------
Terra Tu AV - www.terratu.com
Technical Graphics & Media

[Bob Barrows [MVP]]

Neil Gould wrote:

Or... when is a script not a script?

I have several modules for managing different aspects of our club's
website, most of which are multi-page.

Does setting such things as server.ScriptTi meout or response.buffer
values at the start of the first page persist throughout the session,
or are they "reset" with each function or sub, etc.?

Response.Buffer applies only to the page in which it is called. And it
is not something that is affected by functions or subs running on the
page.
I think the same applies to Server.ScriptTi meout ... the docs don't say
so explicitly, but it would be easy enough to whip up a couple pages,
the first of which sets the ScriptTimeout to some large number and the
second of which checks the setting.

--
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.

[Evertjan.]

Bob Barrows [MVP] wrote on 21 jul 2008 in
microsoft.publi c.inetserver.as p.general:

Response.Buffer applies only to the page in which it is called. And it
is not something that is affected by functions or subs running on the
page.
I think the same applies to Server.ScriptTi meout ... the docs don't say
so explicitly, but it would be easy enough to whip up a couple pages,
the first of which sets the ScriptTimeout to some large number and the
second of which checks the setting.

It seems to stand to logic that since:

Properties of the Response and Request objects are page wide,
properties of the Session object are session wide,
properties of the Application object are application wide,

properties of the Server object should be server wide,
so, [since ASP is the application at hand,
and not the physical server,]
in fact just application wide, too?

However I do not remember having caught MS
being completely logical in specs,
or even building exactly what their specs say,
so the test would be the taste of the pudding,
and reading the specs a mediocre second choice?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Jon Paal [MSMD]]

response.buffer : Indicates whether the current page output is buffered.

server.ScriptTi meout : The ScriptTimeout property specifies the maximum amount of time any script in the application can run before
it is terminated.

[Neil Gould]

Thanks Jon Paal, Bob, and Evertjan,

"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot comwrote in message
news:MP******** *************** *******@posted. palinacquisitio n...

response.buffer : Indicates whether the current page output is buffered.

server.ScriptTi meout : The ScriptTimeout property specifies the maximum

amount

of time any script in the application can run before it is terminated.

Perhaps my experience is being affected by what the defined boundaries of a
"page" vs. "script" vs. "applicatio n" might be.

For instance, on a "page" (mix of ASP and HTML code) that selects files via
a form and calls an ASP file that processes the form but has no direct user
interaction (is that also considered a page?), I received an error that the
response buffer can't be turned off once it is turned on. Well, it was
turned on by an file included on the form processing file. So, that implies
that the boundaries of the ASP file (page?) are defined by the includes as
well. OK, makes sense.

But what about the form that called the routine? If I had set the
response.buffer off on that page, then what (not that it would make sense to
turn it off knowing that it would be turned on again, but this question is
about boundaries rather than proper coding)?

From your comment Jon, if I set the timeout on (or before) the initial page,
will it persist for all later routines and pages? If so, it would make sense
to set the value during the login procedure rather than for each of the
tasks that might be called later, but I don't know if I can trust that some
down-stream action won't time out because of being considered outside the
boundary of one of these elements.

Best,

Neil

[Neil Gould]

Hi,

"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:uv******** ******@TK2MSFTN GP04.phx.gbl...

Neil Gould wrote:

Or... when is a script not a script?

I have several modules for managing different aspects of our club's
website, most of which are multi-page.

Does setting such things as server.ScriptTi meout or response.buffer
values at the start of the first page persist throughout the session,
or are they "reset" with each function or sub, etc.?

Response.Buffer applies only to the page in which it is called. And it
is not something that is affected by functions or subs running on the
page.
I think the same applies to Server.ScriptTi meout ... the docs don't say
so explicitly, but it would be easy enough to whip up a couple pages,
the first of which sets the ScriptTimeout to some large number and the
second of which checks the setting.

Thanks for your comments!
As in my other reply, I'm trying to get a handle on how the boundaries of
these are defined, because it doesn't always work as one might expect. You
can imagine how much I love having to hack the answers to that which should
be clearly documented! ;-)

Best,

Neil

[Jon Paal [MSMD]]

The Active Server Pages (ASP) framework provides six built-in objects:

Application
ObjectContext
Request
Response
Server
Session

Info about the scope of COM Objects in ASP Pages can be found here:

http://msdn.microsoft.com/en-us/library/ms525036.aspx

and here

http://msdn.microsoft.com/en-us/library/aa480423.aspx

[Bob Barrows [MVP]]

Neil Gould wrote:

Thanks Jon Paal, Bob, and Evertjan,

"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot comwrote in
message
news:MP******** *************** *******@posted. palinacquisitio n...

>response.buffe r : Indicates whether the current page output is
buffered.

server.ScriptT imeout : The ScriptTimeout property specifies the
maximum amount of time any script in the application can run before
it is terminated.

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "applicatio n" might be.

For instance, on a "page" (mix of ASP and HTML code) that selects
files via a form and calls an ASP file that processes the form but
has no direct user interaction (is that also considered a page?), I
received an error that the response buffer can't be turned off once
it is turned on. Well, it was turned on by an file included on the
form processing file. So, that implies that the boundaries of the ASP
file (page?) are defined by the includes as well. OK, makes sense.

Yes, includes become part of the page/file

>
But what about the form that called the routine?

It's a different page...
I.E. the requesting form is not part of the response.

If I had set the
response.buffer off on that page, then what (not that it would make
sense to turn it off knowing that it would be turned on again, but
this question is about boundaries rather than proper coding)?

The docs are pretty clear about Buffer. The property is
Response-specific.
The boundaries for a page are from when the page is requested (and the
response begins) to when the response ends. I'm not sure what is
puzzling you about this.

A form or browser sends a request to the server, which loads the
requested page, in which the server-side code runs and sends output to
response. When complete, the response ends.

>
From your comment Jon, if I set the timeout on (or before) the
initial page, will it persist for all later routines and pages?

Despite this being a property of the Server object, I don't think so.
This is where the docs have let me down.
I'm pretty sure the scripttimeout can be set for one page without
affecting it on other pages. I believe I have done this in the past. The
default setting in the website's metadata is in effect unless a page
sets scripttimeout on that particular page..
But again ... take two minutes and try it out. Don't depend on my
memory.
Oh, never mind ... here is a simple test. Run and refresh a page
containing this code:

<%@ Language=VBScri pt %>
<%
Response.Write Server.ScriptTi meout
Server.ScriptTi meout = 100
Response.Write "<BR>"
Response.Write Server.ScriptTi meout
%>

I get 90 (the default) and 100 every time I run this page. It's pretty
clear the scope of the setting is the page.
--
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.

[Neil Gould]

Hi Jon Paal,

Thanks for the pointers. Most of this is the same as in the ASP
documentation that I have. At this point, I'm chasing down a combination of
my misconceptions and anomalous results from following these structures...
it's hard to tell which is which sometimes!

"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot comwrote in message
news:p8******** *************** *******@posted. palinacquisitio n...

The Active Server Pages (ASP) framework provides six built-in objects:

Application
ObjectContext
Request
Response
Server
Session

Info about the scope of COM Objects in ASP Pages can be found here:

http://msdn.microsoft.com/en-us/library/ms525036.aspx

and here

http://msdn.microsoft.com/en-us/library/aa480423.aspx

[Neil Gould]

Hi Bob,

"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:OZ******** ******@TK2MSFTN GP05.phx.gbl...

Neil Gould wrote:

[...]

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "applicatio n" might be.

For instance, on a "page" (mix of ASP and HTML code) that selects
files via a form and calls an ASP file that processes the form but
has no direct user interaction (is that also considered a page?), I
received an error that the response buffer can't be turned off once
it is turned on. Well, it was turned on by an file included on the
form processing file. So, that implies that the boundaries of the ASP
file (page?) are defined by the includes as well. OK, makes sense.
But what about the form that called the routine?

It's a different page...
I.E. the requesting form is not part of the response.

Ah, but it *can* be part of the response, since a form's action can refer to
itself and process correctly. Does that make it "2 pages" from an ASP
perspective?

If I had set the
response.buffer off on that page, then what (not that it would make
sense to turn it off knowing that it would be turned on again, but
this question is about boundaries rather than proper coding)?

The docs are pretty clear about Buffer. The property is
Response-specific.
The boundaries for a page are from when the page is requested (and the
response begins) to when the response ends. I'm not sure what is
puzzling you about this.

What's puzzling me is the concept of a "page" where there are no contents
other than routines. The closest I can come is to consider a "page" to be
the 'P' in 'ASP'. ;-)

A form or browser sends a request to the server, which loads the
requested page, in which the server-side code runs and sends output to
response. When complete, the response ends.

From your comment Jon, if I set the timeout on (or before) the
initial page, will it persist for all later routines and pages?

Despite this being a property of the Server object, I don't think so.
This is where the docs have let me down.
I'm pretty sure the scripttimeout can be set for one page without
affecting it on other pages. I believe I have done this in the past. The
default setting in the website's metadata is in effect unless a page
sets scripttimeout on that particular page..
But again ... take two minutes and try it out. Don't depend on my
memory.
Oh, never mind ... here is a simple test. Run and refresh a page
containing this code:

<%@ Language=VBScri pt %>
<%
Response.Write Server.ScriptTi meout
Server.ScriptTi meout = 100
Response.Write "<BR>"
Response.Write Server.ScriptTi meout
%>

I get 90 (the default) and 100 every time I run this page. It's pretty
clear the scope of the setting is the page.

I agree with your conclusion, which implies that Server.ScriptTi meout (and
what other Server methods???) is not persistent. Thanks!

Best,

Neil