GridView RowEditing Requery question

Discussion in 'ASP .Net Datagrid Control' started by dev648237923, Feb 28, 2007.

  1. dev648237923

    dev648237923 Guest

    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!!!
     
    dev648237923, Feb 28, 2007
    #1
    1. Advertising

  2. 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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.

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



    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Steven Cheng[MSFT], Mar 1, 2007
    #2
    1. Advertising

  3. dev648237923

    dev648237923 Guest

    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]" <> wrote in message
    news:...
    > 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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
    >
    > ==================================================
    >
    >
    >
    > This posting is provided "AS IS" with no warranties, and confers no
    > rights.
    >
    >
    >
    >
    >
    >
    >
    >
     
    dev648237923, Mar 1, 2007
    #3
  4. 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.
     
    Steven Cheng[MSFT], Mar 2, 2007
    #4
  5. dev648237923

    dev648237923 Guest

    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]" <> wrote in message
    news:...
    > 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.
    >
    >
     
    dev648237923, Mar 2, 2007
    #5
  6. 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.
     
    Steven Cheng[MSFT], Mar 5, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Islamegy®

    DataView vs. Datasource requery

    Islamegy®, Mar 1, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    614
    S. Justin Gengo [MCP]
    Mar 1, 2006
  2. =?Utf-8?B?V2lsbCBXaW5u?=

    Gridview RowEditing event problem

    =?Utf-8?B?V2lsbCBXaW5u?=, Apr 25, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    19,369
    =?Utf-8?B?V2lsbCBXaW5u?=
    Apr 25, 2006
  3. egsdar
    Replies:
    0
    Views:
    3,103
    egsdar
    Nov 4, 2008
  4. DavidC

    GridView RowEditing issue

    DavidC, Mar 31, 2010, in forum: ASP .Net
    Replies:
    0
    Views:
    495
    DavidC
    Mar 31, 2010
  5. Shafia

    RowEditing event in GridView

    Shafia, Apr 19, 2005, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    194
    Shafia
    Apr 19, 2005
Loading...

Share This Page