I have a Requery() function for my data.
I call it when !Page.IsPostback to fill the grid (so I set the DataSource
and call DataBind manually).

Now my user clicks Edit in the grid so now RowEditing fires.
In RowEditing I do:
gv.EditIndex = e.NewEditIndex;
Requery();

That all works -- but my concern is: what if someone else added rows in
between the time I did my initial requery (!Page.IsPostback) and the time I
do it now in RowEditing? In that case Requery() will not return the same
DataSet and so the EditIndex I thought I had is in fact different. I tested
this and sure enough that is the case.

How can this problem be handled?
Thanks for any ideas!!!

Hello Matt,

Regarding on the Row Index issue in GridView databinding/updating you
mentioned, I think it is a common case if the DataSource you used to bind
Gridview is always retrieved from database directly(is this your case)?

Actually, for ASP.NET web page, due to the http protocol's stateless
nature, when a page first display to client with databound data, and after
the user submit page to do editing/updating, there may exists some certain
timespan, and there certainly may have occured changed in the backend
database, if it is a frequently updating database.

Therefore, for your scenario, if your backend database may frequently be
changed due to the front application's concurrent access(multi-users
environment),I suggest you consider the following approach:

** Implement local cache in your ASP.NET application(for the data access
component). Whenever you pull some resultset from database, you cached it
in server momey(such as using the ASP.NET application cache) so that before
the cache become invalid, the calling side always get the cached resultset.

** For your GridView(or any other front databound controls), instead of
directly query backend database, you use the local cached dataset (during
the lifecycle of the cached resultset). This can confirm the consistency of
the datasource be bound to GridView(between multiple databinding or page
requests roundtrip).

How do you think?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks -- using local cahced dataset sounds like it will be the way to go
for me. My datasets can get large (5-15MB) -- do you think that is OK to put
in the cache or too big?
Thank you!

"Steven Cheng[MSFT]" <stcheng (AT) online (DOT) microsoft.com> wrote

Thanks for your followup Matt,

Sure, if the dataset is quite large, you do need to consider the memory
pressure it may bring to your server machine. Actually, what I wonder is
whether you'll need to frequently load different (can not share) instances
of such dataset from backend database. Also, if the application is serving
concurrent client users, can such large dataset shared by users or each use
will have an individual copy, if each user will own a specific copy, that
make the memory pressure further critical. For such scenario, I would
suggest you consider some other kind of data editing/updating in your
ASP.NET page. For example, instead of using GridView to do both data
displaying and edting, you can use GridView to display data only, it can
display all the data records in rows, then, for each record, when user
click edit button in GridView, you can popup/display another separate
FormView or DetailsView for editing the selected record, since this record
can be located through its primary key(rather than ItemIndex in GridView),
you can avoid the inconsistency issue in earlier case. How do you think?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

Hi --

I need to keep the editing in the grid because the user edits lots of rows
while working and they want it all in the grid.
In RowUpdating I do use the PK so I am assured I am updating the record that
I made edits for so that is good.
I only need to keep the data cached between the normal view of the grid and
the edit view of the grid (so when they click row 11 that has storeitem 7656
then when row 11 shows up in edit mode it is the one with storeitem 7656). I
think I will try the data cache like you said and then clear it after edit
and then monitor the memory presure on the server -- this is a little used
part of the app so I do not expect concurrent users.
Thanks for your help and info!

"Steven Cheng[MSFT]" <stcheng (AT) online (DOT) microsoft.com> wrote

Thanks for your followup.

If you have any further questions or need any othe help, please feel free
to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.