Session Variables vs HIDDEN fields

[Bob Barrows]

tmurray0539 wrote:

> Hi All:
>
> I am rather new to this ASP thing (but am liking it). I have a
> project that involves lots of
> forms. At some point I have to enter all of the information that was
> contained in the forms
> into a database. Is the best route to go about this?:
>
> 1. As soon as a form is filled and submitted, store the values in
> Session variables
> and then when all the forms have been submitted gather all of
> the Sessions contents and then store in the
> database
>

This will work fine - unless the user has cookies shut off. No cookies: no
sessions.

> OR
>
> 2. Passs each submitted form's values to the next form as hidden
> values and then when the last form has been
> submitted simply populate the database.

This will work, but I don't like passing around a lot of dead weight.

>
> Perhaps there is a better approach then either of what I have thought
> of.
>

I like entering the data into the database as soon as I receive it. I'm not
really clear about why you want to wait until it's all been submitted. What
if a glitch happens after the user submits the 4th form: you're going to
make the user re-enter the data from the first 4 forms ... ? Not very
friendly ...

If there is a reason to wait until the last form is submitted, here are a
couple alternatives:
1. Redesign. Combine some or all of the forms so that a single unit of work
is submitted with a single form submission. All related data entered and
submitted via a single form.

2. Store the data from each form submission in a work table in the database,
identified by the user id. When the last form is submitted, run a stored
procedure or saved query to transfer the data to the actual destination
table.

3. If the goal is to cut down on the trips to the database (and this is a
good goal), you could consider storing the data in a text or xml file in a
folder on the server. The file could be identified by the user's id. when
the last form is submitted, run a routine to read the data from the files,
enter it into the database, and delete the files.

HTH,
Bob Barrows

[tmurray0539]

Hi Bob. Thanks for the quick reply. You are correct, I would like to cut
down on the amount of trips to the database. Here is some background
information to consider:

1. Currently the back end is Access (2002)

2. Each form is a part of a questionnaire. The forms groups related
questions together.

Also, Bob, I think a rather good reason to wait till all the information has
been gathered is because if a user decides to abandon the survey before it
has actually been concluded it is sort of useless to have the database
contain only some of the information that it supposed to contain.

Now that you have a better idea of what I am trying to accoplish, what do
you suggest? The idea where information is stored in a file sounds feasible.
The only problem that I could see with that approach is that a username is
only obtained after all of the information in the survey has been obtained.
This is an issue that I have no control over as the client stipulates that
it be obtained only after the survey has been completed.

Again, I do appreciate your help and look forward to your next response.

Thank you

Terry

[Bob Barrows]

I've been thinking about this, and the "redesign" option is the one I keep
coming back to. I dislike the idea of doing multiple submissions for a
single unit of work (the entire questionnaire being the single unit of
work). A lot of network traffic is being generated via multiple submissions,
and you say yourself that some of that traffic may be unnecessary if the
user abandons the process in the middle.

There should be a way to get all the questions onto a single form. The exact
method used depends on how much control you have over the users' browsers.
Is this an Intranet or Internet application?

Bob Barrows

tmurray0539 wrote:

> Hi Bob. Thanks for the quick reply. You are correct, I would like
> to cut down on the amount of trips to the database. Here is some
> background information to consider:
>
> 1. Currently the back end is Access (2002)
>
> 2. Each form is a part of a questionnaire. The forms groups related
> questions together.
>
> Also, Bob, I think a rather good reason to wait till all the
> information has been gathered is because if a user decides to abandon
> the survey before it has actually been concluded it is sort of
> useless to have the database contain only some of the information
> that it supposed to contain.
>
> Now that you have a better idea of what I am trying to accoplish,
> what do you suggest? The idea where information is stored in a file
> sounds feasible. The only problem that I could see with that approach
> is that a username is only obtained after all of the information in
> the survey has been obtained. This is an issue that I have no control
> over as the client stipulates that it be obtained only after the
> survey has been completed.
>
> Again, I do appreciate your help and look forward to your next
> response.
>
> Thank you
>
> Terry

[tmurray0539]

Hi again Bob. It is an internet application.

Terry

"Bob Barrows" <reb_01501@yahoo.com> wrote in message
news:ea$a%23Q4UDHA.1004@TK2MSFTNGP12.phx.gbl...

> I've been thinking about this, and the "redesign" option is the one I keep
> coming back to. I dislike the idea of doing multiple submissions for a
> single unit of work (the entire questionnaire being the single unit of
> work). A lot of network traffic is being generated via multiple

submissions,

> and you say yourself that some of that traffic may be unnecessary if the
> user abandons the process in the middle.
>
> There should be a way to get all the questions onto a single form. The

exact

> method used depends on how much control you have over the users' browsers.
> Is this an Intranet or Internet application?
>
> Bob Barrows
>
> tmurray0539 wrote:

> > Hi Bob. Thanks for the quick reply. You are correct, I would like
> > to cut down on the amount of trips to the database. Here is some
> > background information to consider:
> >
> > 1. Currently the back end is Access (2002)
> >
> > 2. Each form is a part of a questionnaire. The forms groups related
> > questions together.
> >
> > Also, Bob, I think a rather good reason to wait till all the
> > information has been gathered is because if a user decides to abandon
> > the survey before it has actually been concluded it is sort of
> > useless to have the database contain only some of the information
> > that it supposed to contain.
> >
> > Now that you have a better idea of what I am trying to accoplish,
> > what do you suggest? The idea where information is stored in a file
> > sounds feasible. The only problem that I could see with that approach
> > is that a username is only obtained after all of the information in
> > the survey has been obtained. This is an issue that I have no control
> > over as the client stipulates that it be obtained only after the
> > survey has been completed.
> >
> > Again, I do appreciate your help and look forward to your next
> > response.
> >
> > Thank you
> >
> > Terry

>
>
>

[Bob Barrows]

Well, that certainly limits your options, given that you can't count on
being able to use client-side code given the possibility that users may have
javascript shut off in their browsers.

So, why not put all the questions on a single page? Are there too many of
them? Or do the paricular questions being asked depend on the responses to
prior questions? You could handle this with client-side code, but ...

If you've convinced yourself that you need multiple forms, then let's talk
about persisting the results of each form's submission on the web server. In
order to be able to do this, you are going to have to assign a unique
identifier to each user filling out the questionnaire. I suggest using a
GUID. One way I've seen to do this is this:

<%
guid = server.createobject("scriptlet.typelib").guid
GUID = Left(Right(GUID, Len(GUID)-1), 6) & _
DatePart("d", Now) & DatePart("m", Now) & _
DatePart("yyyy", Now) & DatePart("H", Now) & _
DatePart("N", Now) & DatePart("S", Now)
response.write guid
%>

Or use GUIDMaker from [url]http://www.serverobjects.com/products.htm[/url]

So, when the first form is submitted, get a guid and use that to name the
file containing the data from that form. Include the guid in a hidden field
in each subsequent page.

I suggest using xml, but you can do it in a plain text file. When each page
is submitted, open the file and add the new data until the last form is
submitted.

If you do a Google search on this newsgroup, and on .asp.general, you will
find code for either choice (xml, using loadxml and save; and plain text
using fso). Let us know if you need more details.

Bob Barrows

tmurray0539 wrote:

> Hi again Bob. It is an internet application.
>
> Terry
>

[tmurray0539]

Hi again Bob. I do require multiple forms. I am new to this concept. Once
I create this "guid" what do I do with it or perhaps better put how do I
associate it with each user?

Thanks

Terry

"Bob Barrows" <reb_01501@yahoo.com> wrote in message
news:OW2K$15UDHA.1052@TK2MSFTNGP09.phx.gbl...

> Well, that certainly limits your options, given that you can't count on
> being able to use client-side code given the possibility that users may

have

> javascript shut off in their browsers.
>
> So, why not put all the questions on a single page? Are there too many of
> them? Or do the paricular questions being asked depend on the responses to
> prior questions? You could handle this with client-side code, but ...
>
> If you've convinced yourself that you need multiple forms, then let's talk
> about persisting the results of each form's submission on the web server.

In

> order to be able to do this, you are going to have to assign a unique
> identifier to each user filling out the questionnaire. I suggest using a
> GUID. One way I've seen to do this is this:
>
> <%
> guid = server.createobject("scriptlet.typelib").guid
> GUID = Left(Right(GUID, Len(GUID)-1), 6) & _
> DatePart("d", Now) & DatePart("m", Now) & _
> DatePart("yyyy", Now) & DatePart("H", Now) & _
> DatePart("N", Now) & DatePart("S", Now)
> response.write guid
> %>
>
> Or use GUIDMaker from [url]http://www.serverobjects.com/products.htm[/url]
>
> So, when the first form is submitted, get a guid and use that to name the
> file containing the data from that form. Include the guid in a hidden

field

> in each subsequent page.
>
> I suggest using xml, but you can do it in a plain text file. When each

page

> is submitted, open the file and add the new data until the last form is
> submitted.
>
> If you do a Google search on this newsgroup, and on .asp.general, you will
> find code for either choice (xml, using loadxml and save; and plain text
> using fso). Let us know if you need more details.
>
> Bob Barrows
>
> tmurray0539 wrote:

> > Hi again Bob. It is an internet application.
> >
> > Terry
> >

>
>
>

[Bob Barrows]

A guid is just a string of characters that is supposed to be universally
unique. You can use it as a file's name, or whatever. So, when the first
form is submitted, the "receiving" page, the page that processes the
submission, creates a guid to assign to the submission. It then reads the
data that was submitted by the submitting page, creates an xml document to
contain the data, and uses the Save method to save the data to a file, using
the guid string as the file's name (<guid>.xml). Then, pass the guid to the
next form, either via querystring if redirecting to a new page (not
recommended - makes it easy for somebody to hijack another user's session),
or by setting a hidden textbox's value to the guid string if using response
to generate a new page to be passed to the client. When a subsequent page
submits its data, read the guid from the hidden textbox, and use it to find
the xml file that was previously saved for the user, opening it using the
Load method.
There are code examples illustrating the xml domdocument Load and Save
methods at [url]http://msdn.microsoft.com/library[/url]. I have an example of a
function that creates an xml document from an ADO recordset here:
[url]http://www.davidpenton.com/testsite/tips/xml.data.islands.asp[/url]

I realize that you aren't converting a recordset to xml here, but the
techniques in the BuildXMLfromRSarrays function can be adapted to use with
request.form variables: CreateElement to create a node, SetAttribute to set
an attribute's value, etc. For another example of reading data from an xml
domdocument, get the dynamic listbox example here:
[url]http://www.thrasherwebdesign.com/index.asp?pi=links&hp=links.asp&c=&a=clear[/url]

This example uses client-side code, but it's vbscript, so you should be able
to easily adapt it to use in server-side code.

HTH,
Bob Barrows

tmurray0539 wrote:

> Hi again Bob. I do require multiple forms. I am new to this
> concept. Once I create this "guid" what do I do with it or perhaps
> better put how do I associate it with each user?
>
> Thanks
>
> Terry
>
> "Bob Barrows" <reb_01501@yahoo.com> wrote in message
> news:OW2K$15UDHA.1052@TK2MSFTNGP09.phx.gbl...

>> Well, that certainly limits your options, given that you can't count
>> on being able to use client-side code given the possibility that
>> users may have javascript shut off in their browsers.
>>
>> So, why not put all the questions on a single page? Are there too
>> many of them? Or do the paricular questions being asked depend on
>> the responses to prior questions? You could handle this with
>> client-side code, but ...
>>
>> If you've convinced yourself that you need multiple forms, then
>> let's talk about persisting the results of each form's submission on
>> the web server. In order to be able to do this, you are going to
>> have to assign a unique identifier to each user filling out the
>> questionnaire. I suggest using a GUID. One way I've seen to do this
>> is this:
>>
>> <%
>> guid = server.createobject("scriptlet.typelib").guid
>> GUID = Left(Right(GUID, Len(GUID)-1), 6) & _
>> DatePart("d", Now) & DatePart("m", Now) & _
>> DatePart("yyyy", Now) & DatePart("H", Now) & _
>> DatePart("N", Now) & DatePart("S", Now)
>> response.write guid
>> %>
>>
>> Or use GUIDMaker from [url]http://www.serverobjects.com/products.htm[/url]
>>
>> So, when the first form is submitted, get a guid and use that to
>> name the file containing the data from that form. Include the guid
>> in a hidden field in each subsequent page.
>>
>> I suggest using xml, but you can do it in a plain text file. When
>> each page is submitted, open the file and add the new data until the
>> last form is submitted.
>>
>> If you do a Google search on this newsgroup, and on .asp.general,
>> you will find code for either choice (xml, using loadxml and save;
>> and plain text using fso). Let us know if you need more details.
>>
>> Bob Barrows
>>
>> tmurray0539 wrote:

>>> Hi again Bob. It is an internet application.
>>>
>>> Terry

[Harag]

Thanks for the GUID code placed earlier in this topic it will be
useful for me as well bob.

I was wondering could you help me on some other guid issue.

When a member logs onto my site I would like to create a guid (using
client side javascript) based on that users machine. so when the user
logs on later it will create the SAME guid for the same machine... if
the user logs on using another machine (or another user logs on using
his password/name) then I can refuse the log in. So basically the user
has to log in from the same machine each time.

I have thought about using a cookie but that can be removed or denied.

Thanks for any help.

Al

PS Yes the member will have to option to beable to log in from
multiple machines or from only one machine (multi for cafe etc users
and one for home uses)


On Sat, 26 Jul 2003 16:37:30 -0400, "Bob Barrows"
<reb_01501@yahoo.com> wrote:

>A guid is just a string of characters that is supposed to be universally
>unique. You can use it as a file's name, or whatever. So, when the first
>form is submitted, the "receiving" page, the page that processes the
>submission, creates a guid to assign to the submission. It then reads the
>data that was submitted by the submitting page, creates an xml document to
>contain the data, and uses the Save method to save the data to a file, using
>the guid string as the file's name (<guid>.xml). Then, pass the guid to the
>next form, either via querystring if redirecting to a new page (not
>recommended - makes it easy for somebody to hijack another user's session),
>or by setting a hidden textbox's value to the guid string if using response
>to generate a new page to be passed to the client. When a subsequent page
>submits its data, read the guid from the hidden textbox, and use it to find
>the xml file that was previously saved for the user, opening it using the
>Load method.
>There are code examples illustrating the xml domdocument Load and Save
>methods at [url]http://msdn.microsoft.com/library[/url]. I have an example of a
>function that creates an xml document from an ADO recordset here:
>[url]http://www.davidpenton.com/testsite/tips/xml.data.islands.asp[/url]
>
>I realize that you aren't converting a recordset to xml here, but the
>techniques in the BuildXMLfromRSarrays function can be adapted to use with
>request.form variables: CreateElement to create a node, SetAttribute to set
>an attribute's value, etc. For another example of reading data from an xml
>domdocument, get the dynamic listbox example here:
>[url]http://www.thrasherwebdesign.com/index.asp?pi=links&hp=links.asp&c=&a=clear[/url]
>
>This example uses client-side code, but it's vbscript, so you should be able
>to easily adapt it to use in server-side code.
>
>HTH,
>Bob Barrows
>
>tmurray0539 wrote:

>> Hi again Bob. I do require multiple forms. I am new to this
>> concept. Once I create this "guid" what do I do with it or perhaps
>> better put how do I associate it with each user?
>>
>> Thanks
>>
>> Terry
>>
>> "Bob Barrows" <reb_01501@yahoo.com> wrote in message
>> news:OW2K$15UDHA.1052@TK2MSFTNGP09.phx.gbl...

>>> Well, that certainly limits your options, given that you can't count
>>> on being able to use client-side code given the possibility that
>>> users may have javascript shut off in their browsers.
>>>
>>> So, why not put all the questions on a single page? Are there too
>>> many of them? Or do the paricular questions being asked depend on
>>> the responses to prior questions? You could handle this with
>>> client-side code, but ...
>>>
>>> If you've convinced yourself that you need multiple forms, then
>>> let's talk about persisting the results of each form's submission on
>>> the web server. In order to be able to do this, you are going to
>>> have to assign a unique identifier to each user filling out the
>>> questionnaire. I suggest using a GUID. One way I've seen to do this
>>> is this:
>>>
>>> <%
>>> guid = server.createobject("scriptlet.typelib").guid
>>> GUID = Left(Right(GUID, Len(GUID)-1), 6) & _
>>> DatePart("d", Now) & DatePart("m", Now) & _
>>> DatePart("yyyy", Now) & DatePart("H", Now) & _
>>> DatePart("N", Now) & DatePart("S", Now)
>>> response.write guid
>>> %>
>>>
>>> Or use GUIDMaker from [url]http://www.serverobjects.com/products.htm[/url]
>>>
>>> So, when the first form is submitted, get a guid and use that to
>>> name the file containing the data from that form. Include the guid
>>> in a hidden field in each subsequent page.
>>>
>>> I suggest using xml, but you can do it in a plain text file. When
>>> each page is submitted, open the file and add the new data until the
>>> last form is submitted.
>>>
>>> If you do a Google search on this newsgroup, and on .asp.general,
>>> you will find code for either choice (xml, using loadxml and save;
>>> and plain text using fso). Let us know if you need more details.
>>>
>>> Bob Barrows
>>>
>>> tmurray0539 wrote:
>>>> Hi again Bob. It is an internet application.
>>>>
>>>> Terry

>
>

[Harag]

Thanks for the info but I dont seem to get anything from:

request.servervariable("REMOTE_NAME")

is this the right command?

Also this isn't fullproof as the user could always change the name of
the machine to something else.

any other ideas?

thanks again
Al.

On Sun, 27 Jul 2003 08:05:16 -0400, "Bob Barrows"
<reb_01501@yahoo.com> wrote:

>I would do this server-side (client-side will require you to save a file on
>the user's machine, which cannot be done unless you use HTA). You can get
>the name of the user's machine from the REMOTE_NAME servervariable. Generate
>the GUID and store it in an xml file along with the machine name. Next time,
>open the xml file and look up the GUID using the machine name.
>
>HTH,
>Bob Barrows
>

[Bob Barrows]

Nope. The only alternative is some sort of client-side application
Harag wrote:

> Thanks for the info but I dont seem to get anything from:
>
> request.servervariable("REMOTE_NAME")
>
> is this the right command?
>
> Also this isn't fullproof as the user could always change the name of
> the machine to something else.
>
> any other ideas?
>
> thanks again
> Al.
>
> On Sun, 27 Jul 2003 08:05:16 -0400, "Bob Barrows"
> <reb_01501@yahoo.com> wrote:
>

>> I would do this server-side (client-side will require you to save a
>> file on the user's machine, which cannot be done unless you use
>> HTA). You can get the name of the user's machine from the
>> REMOTE_NAME servervariable. Generate the GUID and store it in an xml
>> file along with the machine name. Next time, open the xml file and
>> look up the GUID using the machine name.
>>
>> HTH,
>> Bob Barrows

[Roy in \(H.E.Double Toothpicks\)]

request.servervariables("REMOTE_Host")


"Bob Barrows" <reb_01501@yahoo.com> wrote in message
news:%23OeETKGVDHA.2164@TK2MSFTNGP10.phx.gbl...

> Nope. The only alternative is some sort of client-side application
> Harag wrote:

> > Thanks for the info but I dont seem to get anything from:
> >
> > request.servervariable("REMOTE_NAME")
> >
> > is this the right command?
> >
> > Also this isn't fullproof as the user could always change the name of
> > the machine to something else.
> >
> > any other ideas?
> >
> > thanks again
> > Al.
> >
> > On Sun, 27 Jul 2003 08:05:16 -0400, "Bob Barrows"
> > <reb_01501@yahoo.com> wrote:
> >

> >> I would do this server-side (client-side will require you to save a
> >> file on the user's machine, which cannot be done unless you use
> >> HTA). You can get the name of the user's machine from the
> >> REMOTE_NAME servervariable. Generate the GUID and store it in an xml
> >> file along with the machine name. Next time, open the xml file and
> >> look up the GUID using the machine name.
> >>
> >> HTH,
> >> Bob Barrows

>
>
>

[Roy in \(H.E.Double Toothpicks\)]

just use session variables and move on.


"Bob Barrows" <reb_01501@yahoo.com> wrote in message
news:%23OeETKGVDHA.2164@TK2MSFTNGP10.phx.gbl...

> Nope. The only alternative is some sort of client-side application
> Harag wrote:

> > Thanks for the info but I dont seem to get anything from:
> >
> > request.servervariable("REMOTE_NAME")
> >
> > is this the right command?
> >
> > Also this isn't fullproof as the user could always change the name of
> > the machine to something else.
> >
> > any other ideas?
> >
> > thanks again
> > Al.
> >
> > On Sun, 27 Jul 2003 08:05:16 -0400, "Bob Barrows"
> > <reb_01501@yahoo.com> wrote:
> >

> >> I would do this server-side (client-side will require you to save a
> >> file on the user's machine, which cannot be done unless you use
> >> HTA). You can get the name of the user's machine from the
> >> REMOTE_NAME servervariable. Generate the GUID and store it in an xml
> >> file along with the machine name. Next time, open the xml file and
> >> look up the GUID using the machine name.
> >>
> >> HTH,
> >> Bob Barrows

>
>
>

[Daniel Bush]

On Sun, 27 Jul 2003 18:05:50 +0100, Harag <harag@softhome.net> wrote:

>Thanks for the info but I dont seem to get anything from:
>
>request.servervariable("REMOTE_NAME")
>
>is this the right command?
>
>Also this isn't fullproof as the user could always change the name of
>the machine to something else.
>
>any other ideas?
>
>thanks again
>Al.
>

It seems to me that your intended users are on an *intra*net. If so,
and they are logging into a domain, then base your GUID (or RowId in
the database) on their domain, domain login, and local address, or

RowId=request.servervariables("LOGON_USER") & _
request.servervariables("LOCAL_ADDR")

Then, if you want to persist their questionnaire answers between
sessions, it will be easy to do so. To use the LOGON_USER variable,
you must go into the Internet Information Server applet on the web
server and change the particular ASP page's Directory Security ...
Uncheck "Anonymous Access" and make sure "Integrated Windows Security"
is checked. Also, it would be very difficult for the average user to
change their IP address.

Thus, you can retrieve/display/update each part of the database row on
each ASP page rather than using XML schemes to save partials (though
in some cases that is an excellant alternative). Just use the RowId
above as the PrimaryKey of that particular table - on each page, check
and see if it exists, if it does, fill in the form values with the
existing values to allow user to change them, if not, create a new
database row with that RowId. If you wish to make sure the user starts
with one form and ends with another, simply check a hidden value in
the form (like PrevPageNo), if it is not there, response.redirect to
page one - if it is there and it is not the correct value, redirect to
the correct page (for instance, if you are on Page 2 of the
questionnaire you must have PrevPageNo = 1, Page 4 should be
PrevPageNo=2, etc). Just make sure you have the
<input type=hidden name=PrevPageNo value=1>
inside the <form></form> block for each page.

BTW, I find it useful to see a list of all the ServerVariables - so I
have a little ASP page to list them for me. Just create an ASP page,
then put this block below the <body> tag.

<Table border=1>
<%
boolBG=true
for each var in Request.ServerVariables
boolBG=NOT boolBG
if boolBG then%>
<tr bgcolor=beige>
<%else%>
<tr>
<%end if%>
<th><%=var%><td><%=Request.ServerVariables(var)% ></tr>
<%next%>
</table>

You can get a lot of good ideas sometimes by looking at what is
available to you via this ASP function.

Dan Bush
[email]me@REMOVE.danbush.com[/email]