FormView, ObjectDataSource and the evil binding

Discussion in 'ASP .Net' started by KaOne, Jun 18, 2007.

  1. KaOne

    KaOne Guest

    Hi All,
    excuse me in advance for my not very perfect english. I need some help about
    a problem with a FormView bounded to an ObjectDataSource. In practise I have
    an ObjectDataSource that uses some BLL methods that implements the
    optimistic concurrency by a TimeStamp field into the DB. So, when I execute
    an insert, update or delete query if I receive 0 like return value from that
    queries I understand that a concurrency problem is occurs so I will inform
    the user.

    The problem comes because, when I'm able to know that a concurrency error is
    occurs is too late, because the only event of the FormView in wich I can
    cancel the databind (by the Cancel property of the FormViewupdateEventArgs
    object) is the ItemUpdating event that, unfortunatelly, occurs BEFORE the
    Updated Event of the ObjectDataSource in wich I can check the concurrency
    error. So, when a concurrency error occurs I can inform the user but I can't
    avoid to reset the FormView with the new value stored into the DB, losting
    all the new values entered by the user.

    How can I solve this problem? Is there a method to cancel the automatic bind
    on the FormView and force id only when I want?

    Thanks a lot.
    KaOne, Jun 18, 2007
    1. Advertisements

  2. Hi KaOne,

    From your description, you're using some custom BLL component class to
    access database for query/updating. And you use Objectdatasource to connect
    them with ASP.NETT 2.0 Formview control. However, since the update method
    of BLL class will indicate concurrent update error as return value, it will
    be too late to inform FormView not to change status, correct?

    Based on my understanding, if your concurrent update error is not raised as
    exception , but an normal return code, the FormView will treat the update
    command as success and change the mode. I think you can have test on the
    following things:

    The FormView control has a "ModeChanging" event, you can add handler and
    print some statement in it to see whether it occurs before your BLL
    component class return update result. If you can get the update result
    first, then you can mark a flag in a page variable or any other place. In
    the Modechanging event, you can cancel the mode changing.

    Also, another means is we manually do the update instead of using the
    FormView's updating command(use another postback button that doesn't use
    "Update" as command name), and only when the update succeed will we
    manually call FormView's ChangeMode method to change the current mode. How
    do you think?


    Steven Cheng

    Microsoft MSDN Online Support Lead


    Get notification to my posts through email? Please refer to

    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


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Jun 19, 2007
    1. Advertisements

  3. KaOne

    KaOne Guest

    Mentre era fermo al semaforo, Steven Cheng[MSFT] prese il suo portatile e
    Hi Steven,
    yes, this is correct. It is my scenario.
    The problem "was" right that. It was a logic error. Now I have changed this
    behavior using a DBConcurrencyException when the result of the UPDATE query
    is 0, so the FormView can treat correctly the situation and I can cancel the
    submit. In this manner the user don't lost their data.

    Thanks a lot for your reply.
    KaOne, Jun 20, 2007
  4. Thanks for your reply KaOne,

    I think your current implementation that manually throw out a exception
    based on the logical error return value is reasonable. Glad that you've
    found the solution on this.

    If you need any further assistance later, please feel free to post here.


    Steven Cheng

    Microsoft MSDN Online Support Lead

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Jun 20, 2007
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.