Question about DLL in ASP

[Fie Fie Niles]

I was given the following scenario, and would like to confirm what the
correct answer will be.

Say you have 3 ASP pages, on each page the user needs to complete
information.
Page 1: first name and last name.
When user click the "next" button, go to Page 2. The ASP page calls a VB DLL
(say Process.DLL) to enter the information for first name and last name.
Page 2: address
When user click the "next" button, go to Page 3. The ASP page calls a VB DLL
(say Process.DLL) to enter the information for address.
Page 3: age
When user click the "save" button, you need to save the information entered
on page 1, 2 and 3 into a database.

The question is: by the time you are on the 3rd page, will the data from
Page 1 and 2 still in the Process.DLL ?

In my opinion, instead of calling the DLL on Page 1 and 2, use Session
variables to store the first name, last name and address from Page 1 and 2.
When you get to Page 3, pass the Session variable to the Process.DLL.
Usually when I call a DLL (Set oProcess =
server.CreateObject("ProcessObject.clsA"), before I exit this ASP page, I
will set the oProcess variable to nothing (set oProcess = nothing). I read
that passing an object like oProcess in a Session variable is not a good
idea.
So, when I get to Page 2, oProcess will be a new instance again, thus the
information from Page 1 won't be there anymore.

Would you please give me your opinion on this. Is the method to call the DLL
on each page a better idea, and will you get all info from Page 1 and 2 by
the time you are on Page 3, or using the Session Variable to store the first
name, last name and address from Page 1 and 2 is a better idea ?

Thank you.

 

[Roji. P. Thomas]

You have to perisist the data somewhere.
DLLS cant keep them in memory and Session variables
are not the right choice.

Save them to the database while the user saves every page.
Use a flag to denote whether the entry is completed, or use an auxilary
table which can be cleared periodically.

 

[John]

You can also transfert the variables from the 1° to the 2° page and store
them in HIDDEN FIELDS

Response.Write "<INPUT TYPE=""HIDDEN"" VALUE=" & Chr(34) &
Request.QueryString("FirstName") & Chr(34) & " NAME=""Firstname"">

 

[fniles]

Thanks.
May I know why using Session variable is not a good idea ?

Also, would you please confirm that passing object variable (like
oProcess from Process.dll) in a session is not a good idea, and that it
is better before I exit the ASP page, to set the oProcess variable to
nothing (set oProcess = nothing) ?

Thank you

 

[fniles]

Thank you.
Passing the variable in the hidden field is a good idea.

Would you please confirm that it is not a good idea to pass an object
variable (like oProcess from Process.dll) in a session variable, and it
is better before I exit the ASP page, to set the oProcess variable to
nothing (set oProcess = nothing) ?

Thanks.

 

[Bob Barrows [MVP]]

Thank you.
Passing the variable in the hidden field is a good idea.

Would you please confirm that it is not a good idea to pass an object
variable (like oProcess from Process.dll) in a session variable,
http://blogs.msdn.com/ericlippert/archive/2003/09/18/53050.aspx

and
it is better before I exit the ASP page, to set the oProcess variable
to nothing (set oProcess = nothing) ?

That's more controversial:
http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx

With ADO objects, it is still my practice to explicitly close and destroy
them in the proper order, since they involve child objects (child objects
need to be released before the poarent objects that created them). With more
well-behaved objects, unless they take up a lot of resources/memory (in
which case they be destroyed as soon as you are finished with them), you can
allow the automatic cleanup to take care of them.

Bob Barrows

 

[Roji. P. Thomas]

http://msdn.microsoft.com/library/default.asp?URL=/library/en-us/dnasp/html/ASPtips.asp