FormView, ObjectDataSource and the evil binding

[KaOne]

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.

 

[Steven Cheng[MSFT]]

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?

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.

 

[KaOne]

Mentre era fermo al semaforo, Steven Cheng[MSFT] prese il suo portatile e
scrisse:

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?

Hi Steven,
yes, this is correct. It is my scenario.

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 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.

 

[Steven Cheng[MSFT]]

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.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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