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

 

[Bob Barrows [MVP]]

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

 

[Evertjan.]

Bob Barrows [MVP] wrote on 21 jul 2008 in
microsoft.public.inetserver.asp.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.ScriptTimeout ... 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?

 

[Neil Gould]

Thanks Jon Paal, Bob, and Evertjan,

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

server.ScriptTimeout : 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. "application" 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,

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

 

[Bob Barrows [MVP]]

Thanks Jon Paal, Bob, and Evertjan,

message

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "application" 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=VBScript %>
<%
Response.Write Server.ScriptTimeout
Server.ScriptTimeout = 100
Response.Write "<BR>"
Response.Write Server.ScriptTimeout
%>

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.

 

[Bob Barrows [MVP]]

Hi Bob,

Neil Gould wrote: [...]

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "application" 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,

No it can't. This is just silly.

What you're saying is analogous to saying that when a sub or function calls
another sub or function, the calling function becomes "part" of the called
sub or function. It is easy to demonstrate that this is not the case:

option explicit
sub caller()
dim callervar
callervar = 3
called 4
end sub
sub called(passed)
response.write callervar + passed
end sub

A request can contain data that is passed to the response, but that does not
make any actions the calling page performed "part of the response".

since a form's action can
refer to itself and process correctly.

No, it is not referring to itself. I don't see where you are getting that.
When a form performs a post or get action, it may include data from itself
to be included with the request, but that is a far cry from being "part of
the request". Think about it. Can server-side code access any of the
client-side (or even server-side) properties of the calling form that were
not passed in the Form or Querystring collection, or persisted to
Application or Session variables?

Does that make it "2 pages"
from an ASP perspective?

Absolutely. Again. From the web server's standpoint, a "page" is defined by:
Everything that occurs from when a response starts until a response ends.
The response starts when the page is requested from the server (even when
the request is being made by the html form that was generated by a previous
request for the same page), and it ends when all the html, hard-coded or
generated, has been sent to the client (or it encounters an explicit
Response.End statement in the code).

That property is in effect until the response ends. Period. See for
yourself:
<%@ Language=VBScript %>
<%
if currbuff = Response.Buffer
Response.Buffer = Not currbuff
Response.Write "Buffer initially set to " & currbuff
Response.Write "<BR>"
Response.Write "Buffer now set to " & Response.Buffer & "<BR>"
%>
<html><body><form method=post>

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'. ;-)

An ASP page generates html to be sent to a client via the Response object.
If your file contains nothing but routines that do not write data to
Response, then this file is probably an include file that is becoming part
of the ASP page that IS writing data to Response.

Think about it this way: when you include a file in an ASP page, you are in
essence creating a new file in memory that contains the contents of both the
included file and the called file: a single page.

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

Huh? Methods perform actions. They don't persist unless the action they
perform causes something to be persisted.

 

[Anthony Jones]

Hi Bob,

Neil Gould wrote: [...]

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "application" 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?

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'. ;-)

I can understand the confusion. The P in ASP does stand for Page but
strictly speaking an ASP is simply an active script file. I think ASF was
already taken though.

The best approach is to forget the term Page altogether just think of them
as script files that receive some special pre-processing before being used
as a script.

In the case where you have a ASP (a script file) containing only functions
you will have to include that as part of another script for it to be of use.
The ASP.dll will build up a script by lexically inserting the includes (and
nested includes). Once the completed script text is built it converts it to
a form of script that can actually be parsed by the choosen scripting
language. Its then executed.

So in this case all server objects are common to all the scripts used as
includes. In addition the scripts share the same script context hence the
identifier namespace is shared between them also. When using includes you
need to watch out for name collisions where two or more of the files may
define the same variable or procedure name. I tend to use Classes in
include files to compartmentalise the namespace.


Another way use supplementary ASP file is to use Server.Execute. In this
case though the executed script has an independant script context. All the
same server objects are exposed in the new context (so for example if
Server.ScriptTImeout was modified earlier during this request processing its
value will remain at the modified value) but none of the calling scripts
variables and procedures would be visible.



Apart form value modified on the Session object and the Application object
nothing else is persisted between individual requests.

 

[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!

 

[Neil Gould]

Hi Bob,

Neil Gould wrote: [...]

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "application" 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?

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.


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=VBScript %>
<%
Response.Write Server.ScriptTimeout
Server.ScriptTimeout = 100
Response.Write "<BR>"
Response.Write Server.ScriptTimeout
%>

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.ScriptTimeout (and
what other Server methods???) is not persistent. Thanks!

Best,

Neil

 

[Evertjan.]

Neil Gould wrote on 22 jul 2008 in
microsoft.public.inetserver.asp.general:

Are you saying that the "page" boundaries are defined by HTML content
sent to the the client?

An ASP page is a text string being interpreted by the asp engine on a get
request, usually being the content of a single serverside file that bears
the name of the requested file.

So why a "page" and not a file? Because that file can be augmented by
includes including the text content of other files. Or the "page" can be
any other string that is imported by such file or by instructions in the
404.asp error system.

In effect the whole compount "file" that is constructed to be read by the
ASP-engine is the page, usually rendering and sending a header plus HTML
content [including clientside scripts] to the requesting client, could also
send any other header plus byte stream.

And the ASP-engine could be instructed to do serverside things unrelated to
the rendered content, like manipulating Session or Application variables
using ASP statements, and like file manipulation, database manipulation or
sending an email, all using specific ASP-external components.

 

[Bob Barrows [MVP]]

Are you saying that the "page" boundaries are defined by HTML content
sent to the the client?

Sort of. The end-boundary is defined by the act of sending the final
piece of html content to the client. If Buffer is on, then no html is
sent to the client until the response ends. If buffering is off, html
can be sent to the client before the end of the response by
Response.Flush. In that case, the response continues until Response.End
is called or asp.dll runs out of code to process in the file.

The "page" starts when asp.dll starts processing a file requested from
the webserver.

If so, I understand why a form that calls
itself would be considered 2 pages from an ASP perspective.

Think of it as being from the web server's, or really, the asp.dll's
perspective.

On the
other hand, the only way that I've been able to get parameters to
persist reliably between functions even in a single ASP file with no
HTML is to set them as Session.Contents.Items (or Application...).

Huh? Now it seems as if you are confused about scope. Variables declared
within functions/subs are only accessible within those functions/subs.
Variables declared outside of functions/subs are accessible to all code
in the scope of the page in which they are declared.

dim globalvar
globalvar=5
function useglobalvar()
response.write globalvar
end function

Maybe I'm not getting what you are talking about: could you provide a
repro to make clear what you are talking about?

Not what I'm asking about. See the example in my reply to Jon Paal. I
have ASP files (pages?) that do not contain HTML and perform other
actions on the server side (logging, updating a database, setting
variables, etc.). Those ASP files may have functions that call a file

By "call a file", are you talking about loading text from a file via
FileScriptingobject? or are you talking about a server-side include
(ssi)?

that contains HTML that is sent to the client, and in such a case, it
is clear that there are two or more pages.

.... and they are sending that html to the client via the response that
was begun when the initially-called file was started to be processed by
asp.dll.

But, what about the ASP
file itself, since it is not an include with the calling file, sends
nothing to the client, and has no Response properties or methods?

Any file that is processed by asp.dll starts and ends a response. Even a
file that makes no explicit mention of the Response object. In such a
case, when the response ends, an empty page is seen by the client
(unless an error occurs). If you are requesting that page using Ajax or
xmlhttprequest, then you will likely not even look at the responsetext
property when calling this file. However, that html is returned - an
empty string is html.

 

[Neil Gould]

Hi Anthony,

In the case where you have a ASP (a script file) containing only functions
you will have to include that as part of another script for it to be of use.

Well, not so fast. For instance, an ASP containing only functions can
process a form that calls it based on parameters set in the form. All that
is necessary to do this is that the tail end of that ASP process via
Request.Form (or a specific action sans Request.Form).

The ASP contains only:
------------------------
<%
FUNCTION DoThis1
....
END FUNCTION
%>

....

<%
FUNCTION DoThisX
....
END FUNCTION
%>

<%
DIM DoWhat
DoWhat = Request.Form("WhatToDo")

SELECT CASE DoWhat
CASE 1
DoThis1
CASE...
DoWhatever...
CASE X
DoThisX
END SELECT
%>
-----------------------------

The ASP.dll will build up a script by lexically inserting the includes (and
nested includes). Once the completed script text is built it converts it to
a form of script that can actually be parsed by the choosen scripting
language. Its then executed.

So in this case all server objects are common to all the scripts used as
includes. [...]

Does not Bob's test of Server.ScriptTimeout dispute this notion? If his ASP
calls itself, as in the above example, what is the expected result?

Best,

Neil

 

[Bob Barrows [MVP]]

Yes, but *values* set for those variables sometimes get dumped before
the subsequent functions/subs can use them. In order to guarantee
persistence, I've had to set those values as

During the same execution of that page?
Show me.

This is clear.

So, a multi-function ASP file may start and end the asp.dll multiple
times,

No. Only if it is called (requested) multiple times.

thus making that file appear as several "pages", and the HTML
is not a delimiter...or am I still conceptually off-base?

Something is surely escaping me here. You really need to show me what
you are talking about.

 

[Bob Barrows [MVP]]

Hi,

[...]
And the ASP-engine could be instructed to do serverside things
unrelated to the rendered content, like manipulating Session or
Application variables using ASP statements, and like file
manipulation, database manipulation or sending an email, all using
specific ASP-external components.

This is the aspect that I'm dealing with most often in trying to get a
handle on persistence issues. Sometimes, variable values that aren't
stored as session items get "lost", and are reported as empty when
tested with response.write or some other means.

Show us.

 

[Neil Gould]

Hi Bob,

Neil Gould wrote: [...]

Ah, but it *can* be part of the response,

No it can't. This is just silly.

What you're saying is analogous to saying that when a sub or function calls
another sub or function, the calling function becomes "part" of the called
sub or function. It is easy to demonstrate that this is not the case:

That isn't how I was using "part", and I agree with you regarding functions
or subs.

I'm trying to grok the boundaries of such things as a "page", and in the
case where a form calls itself, there appears to be only one "page" from an
HTML point of view.

No, it is not referring to itself. I don't see where you are getting that.

I get that from a form's action that posts to the page containing the form
and processes the user input.

Absolutely. Again. From the web server's standpoint, a "page" is defined by:
Everything that occurs from when a response starts until a response ends.
The response starts when the page is requested from the server (even when
the request is being made by the html form that was generated by a previous
request for the same page), and it ends when all the html, hard-coded or
generated, has been sent to the client (or it encounters an explicit
Response.End statement in the code).

Are you saying that the "page" boundaries are defined by HTML content sent
to the the client? If so, I understand why a form that calls itself would be
considered 2 pages from an ASP perspective. On the other hand, the only way
that I've been able to get parameters to persist reliably between functions
even in a single ASP file with no HTML is to set them as
Session.Contents.Items (or Application...). So, I'm unclear about the
boundaries of a "page" in this context.

An ASP page generates html to be sent to a client via the Response object.
If your file contains nothing but routines that do not write data to
Response, then this file is probably an include file that is becoming part
of the ASP page that IS writing data to Response.

Not what I'm asking about. See the example in my reply to Jon Paal. I have
ASP files (pages?) that do not contain HTML and perform other actions on the
server side (logging, updating a database, setting variables, etc.). Those
ASP files may have functions that call a file that contains HTML that is
sent to the client, and in such a case, it is clear that there are two or
more pages. But, what about the ASP file itself, since it is not an include
with the calling file, sends nothing to the client, and has no Response
properties or methods?

Huh? Methods perform actions. They don't persist unless the action they
perform causes something to be persisted.

Sorry for the confusion... written pre-coffee. I know that ScriptTimeout is
the only property of the Server Object.

Best,

Neil

 

[Evertjan.]

Bob Barrows [MVP] wrote on 22 jul 2008 in
microsoft.public.inetserver.asp.general:

Hi,

[...]
And the ASP-engine could be instructed to do serverside things
unrelated to the rendered content, like manipulating Session or
Application variables using ASP statements, and like file
manipulation, database manipulation or sending an email, all using
specific ASP-external components.

This is the aspect that I'm dealing with most often in trying to get a
handle on persistence issues. Sometimes, variable values that aren't
stored as session items get "lost", and are reported as empty when
tested with response.write or some other means.

Show us.

Indeed. Show us an example.

I never lost a value yet,
that is what I value about scripting languages,
as compared to linguistic languages,
where values are often handled like garbage.

Many scripting languages make use of a garbage collector,
but only to collect variables that are already orphaned.

 

[Anthony Jones]

Hi Anthony,


Well, not so fast. For instance, an ASP containing only functions can
process a form that calls it based on parameters set in the form. All that
is necessary to do this is that the tail end of that ASP process via
Request.Form (or a specific action sans Request.Form).

The ASP contains only:
------------------------
<%
FUNCTION DoThis1
...
END FUNCTION
%>

...

<%
FUNCTION DoThisX
...
END FUNCTION
%>

<%
DIM DoWhat
DoWhat = Request.Form("WhatToDo")

SELECT CASE DoWhat
CASE 1
DoThis1
CASE...
DoWhatever...
CASE X
DoThisX
END SELECT
%>

I think you are really struggling with the nomenclature here. The above
ASP doesn't "only contain functions" The Select Case code is in the global
space and will execute as part the a response to a form post. An ASP page
that contains only functions would only contain code bracketed by
Function/End Function and therefore when executed would do nothing.

What you mean is an ASP page that contains no significant text outside of <%
%> which would be sent to the response. (Note that whitespace such as is in
your code above can be sent).

Are you saying the code does nothing to the Response object or that the code
only use Response.Write etc to generate output?

Note that effectively anything between %> <% (that is anything outside of
the script delimiters) effectively becomes a Response.BinaryWrite which
sends the bytes found between a closing %> and an opening <%. The parser
having replaced %> <% and anything in between with such a psuedo binarywrite
now has pure script that it can parse. (Actually its a little more complex
than that but its a good working mental model).

The ASP.dll will build up a script by lexically inserting the includes (and
nested includes). Once the completed script text is built it converts

it

to
a form of script that can actually be parsed by the choosen scripting
language. Its then executed.

So in this case all server objects are common to all the scripts used as
includes. [...]

Does not Bob's test of Server.ScriptTimeout dispute this notion? If his ASP
calls itself, as in the above example, what is the expected result?

I'm not sure how an ASP calls itself? It has created functions which are
then called by the code. This all happens as part of the processing of a
single request. If you changed ScriptTimeout outside of a function and
then checked it value inside a function you would find it has the same
value.

Once the request processing is completed the Script context is reset
including the ScriptTimeout, the only data that can persist beyond that is
Session and Application.

 

[Neil Gould]

Hi Bob,

Sort of. The end-boundary is defined by the act of sending the final
piece of html content to the client. If Buffer is on, then no html is
sent to the client until the response ends. If buffering is off, html
can be sent to the client before the end of the response by
Response.Flush. In that case, the response continues until Response.End
is called or asp.dll runs out of code to process in the file.

The "page" starts when asp.dll starts processing a file requested from
the webserver.

This is how I understood the "page" to be defined from the literature.
However, some unexpected results of treating ASP code in this manner raised
the questions that I've been asking, particularly regarding the persistence
of certain aspects such as variable values, results of processing, etc.

Think of it as being from the web server's, or really, the asp.dll's
perspective.

Got it. But, that implies that a single ASP file can be "seen" as more than
one "page" if it contains multiple functions. And, that describes the
behavior that I've observed and am struggling to grasp.

Huh? Now it seems as if you are confused about scope. Variables declared
within functions/subs are only accessible within those functions/subs.
Variables declared outside of functions/subs are accessible to all code
in the scope of the page in which they are declared.

Yes, but *values* set for those variables sometimes get dumped before the
subsequent functions/subs can use them. In order to guarantee persistence,
I've had to set those values as Session.Contents.Item(s). Works, but I don't
know why the variable values were lost, except for the possibility that the
single ASP file is "seen" as several "pages", and those values don't persist
across pages.

Maybe I'm not getting what you are talking about: could you provide a
repro to make clear what you are talking about?

I think we're getting closer to talking about the same thing (as below).

Any file that is processed by asp.dll starts and ends a response.

This is clear.

So, a multi-function ASP file may start and end the asp.dll multiple times,
thus making that file appear as several "pages", and the HTML is not a
delimiter...or am I still conceptually off-base?

Best,

Neil

 

[Neil Gould]

Hi,

[...]
And the ASP-engine could be instructed to do serverside things unrelated to
the rendered content, like manipulating Session or Application variables
using ASP statements, and like file manipulation, database manipulation or
sending an email, all using specific ASP-external components.

This is the aspect that I'm dealing with most often in trying to get a
handle on persistence issues. Sometimes, variable values that aren't stored
as session items get "lost", and are reported as empty when tested with
response.write or some other means.

Best,

Neil