DataAdapter update

[Janaka]

I tend to use the SqlDataAdapter class in WinForms projects because once the
inital data is loaded any modifications can be easily added/updated through
a call to the Update() method. I've found in aspnet that the same thing is
possible but because of the stateless nature of the web in order to do this
I have to go through the following steps:

1. First visit to page loads DataSet and binds DataList with data
2. User edits data and submits the pages
3. Reload the DataSet with original data as in 1.
4. Iterate through the DataList and updates rows in the DataSet
5. Call the Update() method to update edited rows

Now am I doing this correctly or is there any way I can skip step 3? It
seems easier to just update each row in the DataList than go through the
process of only updating modified rows.

 

[GrantMagic]

i believe saving the dataset into a viewstate would solve your problem,
but beware of the infamous "invalid viewstate" error!!!

I think there is a better solution out there though. anyone???

 

[Cor Ligthert]

Janaka,

You can just add it to a session.item
session.item("ds")=ds

And than back again of course.

I hope this helps

Cor

 

[Janaka]

Thanks that would be my choice as well, howerver the application is not
using Session state so I cannot store any objects in a session.

 

[Cor Ligthert]

Thanks that would be my choice as well, howerver the application is not

using Session state so I cannot store any objects in a session.

How did you exclude that?

Cor

 

[Janaka]

thats set in the web.config

<sessionState mode="Off" />

 

[Cor Ligthert]

Janaka,

Where do you than store your information between pages?

Cor

 

[Hermit Dave]

well i dont tend to disable session.. but i never to use it. that way you
never get into trouble.
well i store user info in the ticket and thats about all the info i need.

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)

 

[Cor Ligthert]

Hermit,

well i dont tend to disable session.. but i never to use it. that way you
never get into trouble.
well i store user info in the ticket and thats about all the info i need.

What troubles exist with session items?


Cor

 

[Janaka]

Sorry guys but if you want to discuss storing session information can you do
this in a new thread? I'm still needing an answer to my original question.
Thanks

 

[Cor Ligthert]

Janaka,

That is easy, that is answered by Gran Magic the viewstate, or the way you
do it now.
However that dataview sends your dataset to the client and back.

There are no better alternatives without a session.

Cor

 

[Janaka]

Ok thanks I just wanted to check. I'm not 100% certain of the viewstate as
storing large DataSets in viewstate is prone to errors I've found

 

[Cor Ligthert]

Janaka,

I forgot one thing, when you use the method with the database, you should be
aware that it can be changed when reading back. This can as well happen with
the other methods, where you have to checkfor concurrency errors.

Cor

 

[Girish bharadwaj]

Following are the options for states in ASP.NET.
1. Cookies.
2. ViewState
3. Session state
4. Application
5. Cache

Among these, if you dont want to use session state, you can probably use
Application or Cache. I recommend Cache since that will basically take care
of cleaning up old items.

You might be able to use ViewState too but you will need to test to make
sure that it does not cause much problems.

 

[Cor Ligthert]

Girish,

Among these, if you dont want to use session state, you can probably use
Application or Cache. I recommend Cache since that will basically take care
of cleaning up old items.

And than use the information in the Cookie to recognize the user, to whom
the dataset belongs?

Cor

 

[Hermit Dave]

Janaka,

okay to answer your quetion you need the an instance of the dataset that you
can modify with changes done by the user
to do that you have three option
a. store it in viewstate
b. store it in session
c. execute the same query to generate the dataset during the postback event
handler for update.

you can disable viewstate on the datagrid (it also add an instance of
datasource) and get better performance.
if you where to do that on every postback you will need to run the original
query and bind the dataset to the datagrid (for paging to work)

if you go on that path then you are generating the dataset either way and
you can set it as a private variables.
if you event handler for update.. you can check to see if dataset was
populated by page_load and then use that dataset and iterate the datagrid
items to update the changes to original dataset before calling update.

And sorry for hijacking your thread

Cor > will try to answer as briefly as possible. Session state reduces
scaleablity. if you write a stateless apps its easy to deploy it in a
webfarm.. if you want more info you will find tons of it on the net. if not
message me or start a new thread and i will & hopefully other users will
post their comments.

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)

 

[Janaka]

Ok thanks Dave.

Janaka,

okay to answer your quetion you need the an instance of the dataset that
you can modify with changes done by the user
to do that you have three option
a. store it in viewstate
b. store it in session
c. execute the same query to generate the dataset during the postback
event handler for update.

you can disable viewstate on the datagrid (it also add an instance of
datasource) and get better performance.
if you where to do that on every postback you will need to run the
original query and bind the dataset to the datagrid (for paging to work)

if you go on that path then you are generating the dataset either way and
you can set it as a private variables.
if you event handler for update.. you can check to see if dataset was
populated by page_load and then use that dataset and iterate the datagrid
items to update the changes to original dataset before calling update.

And sorry for hijacking your thread

Cor > will try to answer as briefly as possible. Session state reduces
scaleablity. if you write a stateless apps its easy to deploy it in a
webfarm.. if you want more info you will find tons of it on the net. if
not message me or start a new thread and i will & hopefully other users
will post their comments.

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)

 

[Cor Ligthert]

Hermit,

Thanks,

Clear,

On the other part of the message, this is a public usenetgroup (or
newsgroup). Not a Microsoft helpdesk, purpose form usenet are discussions
about a question with the purpose to learn each other.

Everytime creating a new thread is (as far as I know) not conform the
nettiquette from usenet.

Cor

"Hermit Dave"

Janaka,

okay to answer your quetion you need the an instance of the dataset that you
can modify with changes done by the user
to do that you have three option
a. store it in viewstate
b. store it in session
c. execute the same query to generate the dataset during the postback event
handler for update.

you can disable viewstate on the datagrid (it also add an instance of
datasource) and get better performance.
if you where to do that on every postback you will need to run the original
query and bind the dataset to the datagrid (for paging to work)

if you go on that path then you are generating the dataset either way and
you can set it as a private variables.
if you event handler for update.. you can check to see if dataset was
populated by page_load and then use that dataset and iterate the datagrid
items to update the changes to original dataset before calling update.

And sorry for hijacking your thread

Cor > will try to answer as briefly as possible. Session state reduces
scaleablity. if you write a stateless apps its easy to deploy it in a
webfarm.. if you want more info you will find tons of it on the net. if not
message me or start a new thread and i will & hopefully other users will
post their comments.

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)

 

[Hermit Dave]

well i did hijack the thread my bad.

PS: there are pros and cons of using session (you can use stateserver or sql
server and that way you can have it in a farm) but you have to serialize the
objects for setting them and things like that. plus things stored in session
are only available for session duration. that means having to constantly do
a
if(Session["Variable"] != null)
{
// fetch the values
}
if you are using state server or sql server, you are either way making
network calls so why not do a straightforward network call instead.

If you are using Frames you sometimes get to see the funny / wierd side of
session.

sometimes though its not just worth the effort at that point Session
variables win for the ease.

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)

 

[Hermit Dave]

also as girish suggested you can use the Application / Cache object.
Though i would advise you to always use Cache instead of Application.
Cache handles the object in a better way and a memory overload on
application object can cause worker process to bounce. ie restart your
application. Cache on the otherhand starts releasing items based on
priority. Also with cache you can set a item release callback which is
called when a particular item is released (so that you could so things like
fetch it again) and things like cache duration etc.

--

Regards,

Hermit Dave
(http://hdave.blogspot.com)