Preferred way of passing data

[Rod]

I've written 2 ASP.NET applications (I've worked on one with a team and
another by myself). In my ASP.NET pages, when saving data to a backend
database I've done it by using the click event of a button and just using
the data during postback.

Now, however, I've got a WebForm that I'll be working on, and it is going to
collect more data than I have collected from the user in the past. I want to
be able to attempt to save each part and if any data element won't be saved,
then go ahead and continue processing the data until all of the entered data
is either saved or failed in the attempt. And then I wanted to inform the
user of the success and failure of trying to save each of the data elements.
Since there is more data now then before, I thought I would have to do what
I've seen done elsewhere on the Web and that is have the user enter all of
their data, press a button and go to some other page in order to save the
data as well as letting the user know the status of their trying to save the
data.

I've read of various ways of solving my problem:

Pass data from one WebForm to another WebForm by:
1) putting the data into the QueryString
2) putting the data into the Session object
3) putting the data the Context object's Items collection
I have also seen an article on MSDN titled "Passing Server Control Values
Between Pages" (
http://msdn.microsoft.com/library/de...tweenpages.asp )
..

And I have a book titled, "ASP.NET Unleashed: Second Edition" by Stephen
Walther (published by SAMS; ISBN: 0-672-32542-x) which says, "To take full
advantage of the ASP.NET framework, you should not create HTML forms that
post to a separate page. If a form posts to another page, any view state
maintained by the page is lost. ... The preferred method for working with
forms in the ASP.NET framework is to post forms back to the same page. ...
After you perform a postback, you can use the Response.Redire ct method to
send a user a new page." (Appendix A, under the heading "Forms Should Post
Back to the Same Page", pp. 1361-1362.)

OK, now I am REALLY confused! I can accept and appreciate the fact that
there is more than one way to do whatever it is you want to do in ASP.NET.
What I would like to know is, what is the preferred way of handling a large
amount of data that you want to attempt to save and then report back to the
user the status of the attempt of saving. What is the "best practice", if
you will, of doing this?

Rod

[Lucas Tam]

"Rod" <ro**@newsgroup s.nospam> wrote in
news:uF******** ******@TK2MSFTN GP11.phx.gbl:

What I would like to know is, what is the preferred way of handling a
large amount of data that you want to attempt to save and then report
back to the user the status of the attempt of saving. What is the
"best practice", if you will, of doing this?

For large amounts of data, I would use a Session object.

Cookies and Query strings are limited in size. ViewState will degrade
performance because data has to travel back and forth between the client
and server, increasing the page payload.

--
Lucas Tam (RE********@rog ers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

[Kevin Spencer]

Think of all the various elements of ASP.Net as tools. Each has different
characteristics , and is best suited for certain types of purposes. Just as
with carpentry tools, there is no "best" tool, only the best tool for the
job at hand.

My advice is to get very familiar with all of the tools, what each one is
designed for, and the characteristics of each, so that you can make an
educated decision whenever you need to choose from a set of possible tools.
In any given situation, only ONE will be the best for the job at hand.

Your confusion stems from the fact that, while you have heard or read about
all of these tools, you don't yet have the intimate knowledge necessary to
make a choice between them. Spending some time familiarizing yourself fully
with them will not only answer your present question, but future ones as
well.

This approach takes more time (and work!) in the short run, but saves you
much more time in the long run.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Rod" <ro**@newsgroup s.nospam> wrote in message
news:uF******** ******@TK2MSFTN GP11.phx.gbl...

I've written 2 ASP.NET applications (I've worked on one with a team and
another by myself). In my ASP.NET pages, when saving data to a backend
database I've done it by using the click event of a button and just using
the data during postback.

Now, however, I've got a WebForm that I'll be working on, and it is going to collect more data than I have collected from the user in the past. I want to be able to attempt to save each part and if any data element won't be saved, then go ahead and continue processing the data until all of the entered data is either saved or failed in the attempt. And then I wanted to inform the
user of the success and failure of trying to save each of the data elements. Since there is more data now then before, I thought I would have to do what I've seen done elsewhere on the Web and that is have the user enter all of their data, press a button and go to some other page in order to save the
data as well as letting the user know the status of their trying to save the data.

I've read of various ways of solving my problem:

Pass data from one WebForm to another WebForm by:
1) putting the data into the QueryString
2) putting the data into the Session object
3) putting the data the Context object's Items collection
I have also seen an article on MSDN titled "Passing Server Control Values
Between Pages" (
http://msdn.microsoft.com/library/de...tweenpages.asp ) .

And I have a book titled, "ASP.NET Unleashed: Second Edition" by Stephen
Walther (published by SAMS; ISBN: 0-672-32542-x) which says, "To take full
advantage of the ASP.NET framework, you should not create HTML forms that
post to a separate page. If a form posts to another page, any view state
maintained by the page is lost. ... The preferred method for working with
forms in the ASP.NET framework is to post forms back to the same page. ...
After you perform a postback, you can use the Response.Redire ct method to
send a user a new page." (Appendix A, under the heading "Forms Should Post
Back to the Same Page", pp. 1361-1362.)

OK, now I am REALLY confused! I can accept and appreciate the fact that
there is more than one way to do whatever it is you want to do in ASP.NET.
What I would like to know is, what is the preferred way of handling a large amount of data that you want to attempt to save and then report back to the user the status of the attempt of saving. What is the "best practice", if
you will, of doing this?

Rod

[Rod]

We are using the Session object for some things, and perhaps that is the
best way to go.

Rod

"Lucas Tam" <RE********@rog ers.com> wrote in message
news:Xn******** *************** ****@140.99.99. 130...

"Rod" <ro**@newsgroup s.nospam> wrote in
news:uF******** ******@TK2MSFTN GP11.phx.gbl:

What I would like to know is, what is the preferred way of handling a
large amount of data that you want to attempt to save and then report
back to the user the status of the attempt of saving. What is the
"best practice", if you will, of doing this?

For large amounts of data, I would use a Session object.

Cookies and Query strings are limited in size. ViewState will degrade
performance because data has to travel back and forth between the client
and server, increasing the page payload.

--
Lucas Tam (RE********@rog ers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

[Rod]

My experience is rather limited; we've only used the Session object and the
QueryString. So, you are correct, I don't have experience with all of the
tools in the toolbox, to you user analogy (good analogy, I might add). I
was just hoping to gain from others experience, that is all.

Thank you, Kevin.

Rod

"Kevin Spencer" <ks******@takem pis.com> wrote in message
news:uN******** ******@TK2MSFTN GP09.phx.gbl...

Think of all the various elements of ASP.Net as tools. Each has different
characteristics , and is best suited for certain types of purposes. Just as
with carpentry tools, there is no "best" tool, only the best tool for the
job at hand.

My advice is to get very familiar with all of the tools, what each one is
designed for, and the characteristics of each, so that you can make an
educated decision whenever you need to choose from a set of possible tools. In any given situation, only ONE will be the best for the job at hand.

Your confusion stems from the fact that, while you have heard or read about all of these tools, you don't yet have the intimate knowledge necessary to
make a choice between them. Spending some time familiarizing yourself fully with them will not only answer your present question, but future ones as
well.

This approach takes more time (and work!) in the short run, but saves you
much more time in the long run.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Rod" <ro**@newsgroup s.nospam> wrote in message
news:uF******** ******@TK2MSFTN GP11.phx.gbl...

I've written 2 ASP.NET applications (I've worked on one with a team and
another by myself). In my ASP.NET pages, when saving data to a backend
database I've done it by using the click event of a button and just using the data during postback.

Now, however, I've got a WebForm that I'll be working on, and it is going

to

collect more data than I have collected from the user in the past. I

want to

be able to attempt to save each part and if any data element won't be saved,

then go ahead and continue processing the data until all of the entered

data

is either saved or failed in the attempt. And then I wanted to inform

the user of the success and failure of trying to save each of the data

elements.

Since there is more data now then before, I thought I would have to do

what

I've seen done elsewhere on the Web and that is have the user enter all of

their data, press a button and go to some other page in order to save

the data as well as letting the user know the status of their trying to save

the

data.

I've read of various ways of solving my problem:

Pass data from one WebForm to another WebForm by:
1) putting the data into the QueryString
2) putting the data into the Session object
3) putting the data the Context object's Items collection
I have also seen an article on MSDN titled "Passing Server Control Values Between Pages" (

http://msdn.microsoft.com/library/de...tweenpages.asp )

.

And I have a book titled, "ASP.NET Unleashed: Second Edition" by Stephen
Walther (published by SAMS; ISBN: 0-672-32542-x) which says, "To take full advantage of the ASP.NET framework, you should not create HTML forms that post to a separate page. If a form posts to another page, any view state
maintained by the page is lost. ... The preferred method for working with forms in the ASP.NET framework is to post forms back to the same page. .... After you perform a postback, you can use the Response.Redire ct method to send a user a new page." (Appendix A, under the heading "Forms Should Post Back to the Same Page", pp. 1361-1362.)

OK, now I am REALLY confused! I can accept and appreciate the fact that
there is more than one way to do whatever it is you want to do in ASP.NET. What I would like to know is, what is the preferred way of handling a

large

amount of data that you want to attempt to save and then report back to

the

user the status of the attempt of saving. What is the "best practice", if you will, of doing this?

Rod

[Anon-E-Moose]

"Rod" <ro**@newsgroup s.nospam> wrote in news:#vyLcQ3iEH A.556
@tk2msftngp13.p hx.gbl:

We are using the Session object for some things, and perhaps that is the
best way to go.

Here's sort of a guide to help you:

If you want to bookmark the page: Querystring
If you're saving information for only one page: ViewState
If you want to save a large object over multiple pages: Session Variable
If you wish to tag a user over a prologed period of time: Cookies