I am using a FormView to update an existing SQL Server record. The rows from the sqldatasource display fine in the FormView and I can edit them. When I click Update, I get the ItemUpdating event but not the ItemUpdated event and the revisions are not written to the database.
Can anyone help me in this please.
In your ItemUpdating event handler, make sure of the following things:
-If you are not using optimistic concurrency checking, remove any old values the FormView may be placing in the OldValues collection.
-Make sure that all of the parameters required by your stored procedure, query, or data source have values and are named correctly in either the Keys or NewValues collections (and make sure that no duplicates exist).
In some cases (usually when an ObjectDataSource is involved), I've had to override the values set by the FormView control, by doing something like this:
protected void myFormView_ItemUpdating(object sender, FormViewUpdateEventArgs e)
{
// remove the old values
e.Keys.Clear();
e.OldValues.Clear();
e.NewValues.Clear();
// set the parameter for the key
e.Keys.Add("#key", valueGoesHere);
// set other parameters
e.NewValues.Add("#param1", aValue);
e.NewValues.Add("#param2", anotherValue);
}
It's not pretty, but it give you absolute control over what gets passed to the DataSource. Generally you should not have to do this if the controls in your FormView are all bound using Bind() for two-way databinding (instead of Eval), but at the very least you could put a break point in ItemUpdating and open up the e.Keys, e.OldValues, and e.NewValues collections to see if the contents are what you expected.
A next step would be to launch SQL Server Profiler to run a trace and examine the actual query being performed.
If you take out the ItemUpdating event and the ItemUpdated event, does your SQL statement execute without errors?
If so, why don't you post some of the code you are using?
Can we see what the sqldatasource looks like? Did you remember to put all the parameters in the sqldatasource under the insert and update parameters list?
Oh also are you setting the cancel property at all in the itemupdating event?
Related
Assuming I have access to the object that would be databound, and the settings for the databinding DataField, FormatString, etc...
How would I programattically get the resulting string value of a databinding without actually databinding to a control?
Context: This is in the overloaded InitializeCell event of a Telerik (Telerik.Web.UI) GridDropDownColumn that I am inheriting. I want to cache the resulting string value, but I need the value before the normal databinding event fires.
Just do a separate database query early in the page life cycle (pre-init) and cache the value manually...
I have a GridView control on my page which is connected with ObjectDataSource where TypeName="BLL.MyLogic" DataObjectTypeName="BLL.MyObject" UpdateMethod="MyUpdateMethod".
The update in MyUpdateMethod is conditional which I am checking the conditions before _datacontext.submitchanges(). Depending on my check I throw exceptions like ("not unique") or ("no appropiate logic found") etc. I am catching these exceptions at page level via OnUpdated="MyDataUpdated" of my ObjectDataSource.
These operations just work fine. Problem is after the process is done and even in the case of "exception occured" the GridView gets reloaded and editindex = -1 (initiated). Even if I manually retrieve the editindex and make it editable the form data (data input by user) in the edittemplate gets wipped away. ViewState doesnt work here.
What is the work around to this situation ?
Thanks in advance.
Have you tried setting the GridViewUpdatedEventArgs.KeepInEditMode property to true in your RowUpdated event handler?
Take for example a DetailsView control with an ObjectDataSource as its datasource.
Normally in the DetailsView.ItemUpdated event I would grab a reference to the details view by casting the sender:
DetailsView dv = (DetailsView)sender;
In certain situations it becomes necessary to handle the event inside the ObjectDataSource.ItemUpdated event. In this case sender is now of type ObjectDataSource. What I want to be able to do is write clean code that isnt hardcoded like
Label label1 = DetailsView1.FindControl("Label1");
I looked over the documentation and also did some searches but couldnt find how I would write some code like the following:
protected void ObjectDataSource1_Inserted(object sender, ObjectDataSourceStatusEventArgs e)
{
ObjectDataSource ods = (ObjectDataSource)sender;
DetailsView dv = (DetailsView)ods.SOMETHING_HERE;
}
Does anyone know what I should be putting in the SOMETHING_HERE in the snippet above?
That's happen because the "OnInserted" event is suppose to be an event examine the values of a return value or output parameters, or to determine whether an exception was thrown after an Insert operation has completed. The return value, output parameters, and exception handling properties are available from the ObjectDataSourceStatusEventArgs object that is associated with the event.
What you can do here is just call ObjectDataSource.select() that returns the view in this case but I don't think it's a good choice.
You should review you business logic and try to manage it somewhere it makes more sense
Anyway your code should look like the below:
ObjectDataSource ods = YourDataSource.select();
DetailsView dv = (DetailsView)ods;
Considering the example you provided, I don't think there is anything you can replace for Something_Here. It is the ODS linked to DV and not the other way. Also one DataSource can be linked to several DataBound Controls.
So as far as I know it is simply not possible.
1) Suppose GridView1 is bound to ObjectDataSource and that GridView1.SelectedIndex is set to value 7. If we then rebind GridView1 by calling GridView1.DataBind(), GridView.SelectedIndex will still retain its initial value ( 7 ).
Are there any other properties which GridView remembers across rebinding operations?
2) Suppose GridView1 is bound to ObjectDataSource control. When GridView1’s row gets deleted, we can call GridView1.DataBind() inside GridView1.RowDeleted event handler to retrieve values from data source. If we don’t call Gridview1.DataBind inside that event handler, then DataBind() will automatically be called by Asp.Net and the result will be the same.
So are there any reasons why we should manually call GridView.DataBind( inside RowDeleted event handler ) instead of letting Asp.Net call it automatically?
Your answer lies in Page.DataBind and Control.DataBind methods.
The main difference is that all data sources are bound to their server controls after the Page.DataBind method is called. No data is rendered to the control until you explicitly call either the DataBind method of the Web server control or until you invoke the page-level Page.DataBind method. Typically, Page.DataBind (or DataBind) is called from the Page_Load event.
Source
Particular answer for 1) is there's no such property for GridView,but you can make your own one and add last changed control.(Ideal)
For 2)Your action here coming from a postback,because the default bound source is changed after all you deleted a row inside it,since default source cannot be bound again,you need to call DataBind manually.
I'm going to mention a bit about Hierarchical Data Binding for starters.
In order to bind a datasource to a server-side control (GridView,DetailsView,.. etc) , that control must support a property known as DataSource and a method known as DataBind() , and the datasource that control is bound implement IEnumerable interface.
There is an exception for DataSet and DataTable which can be both bound directly , which results in binding to the default DataView of default table.
To bind a data to a control , you assign the data source to the DataSource property of the control and call its DataBind() method.Source
Since in your case ,databinding situation is different as you mentioned earlier that you bind GridView with ObjectDataSource which executes a query in page load and in every SELECT,INSERT,UPDATE,DELETE operations,datasource is bound automatically (which means DataBind is also called automatically).
There is another case which you are looking for an answer in the first place is that if datasource is queried and bound in page events (i.e. you query something and get a result with DataTable and bind it into GridView --> this source is not in the page not a objectdatasource or something else stands on page as static source).Since this query is coming from an event,when you enable pageIndex you must query it again that leads to you must also bind it with DataBind.
DataTable sourceTable = GetDataFromServer();
gridView.DataSource = sourceTable;
gridView.DataBind();
I hope that you can understand this time.
I have a gridview with a DataSourceID set, so the databinding happens automatically. The problem is that sometimes, the procedure defined in the SqlDataSource takes a very long time to finish, so the binding comes with a timeout expired error.
How can I catch this error without manually databinding the gridview and surrounding it with try/catch statements?
If an exception occurs when the SqlDataSource is executing, it fires its appropriate post-action event - Selected, in this case. You can optionally create an event handler for this event and in the event handler say that you've handled the exception.
This diagram shows how this interaction works with the ObjectDataSource (the concept is the same with the SqlDataSource control). When examining the diagram below, replace the words "ObjectDataSource" with "SqlDataSource" and "Underlying Object" with "Database" to have it be pertinent for the SqlDataSource.
As you can see, the Selecting event is raised before the data is sent off to the database and the Selected event is raised after the data comes back (or if there's an exception).
You can create a Selected event handler in your page and check to see if an exception occurred and decide whether you want to handle it yourself. Fredrik Normen has a good blog entry on this: Handle the data-source control exception by your own.
Additional reading material: Accessing and Updating Data in ASP.NET: Examining the Data Source Control's Events.
Happy Programming!
Why not fix the problem with the query timing out instead? Either optimise the DB (preferred) or set the connection/command timeout to be higher than the current value.
You can adjust the timeout as follows by hooking into the SqlDataSource Selecting event:
protected void ds_Selecting(object sender, SqlDataSourceSelectingEventArgs e)
{
e.Command.CommandTimeout = 5000;
}
If you are using SQL Server you might want to look at tools like the index tuning wizard/tuning advisor, show query execution plan or SQL Server Profiler.
how about binding asynchronously? once completed, the callback function can call databind if no errors were returned.
EDIT: I guess that's manual...not what you wanted.
The only think you can do is handling the Page_Error Event
http://msdn.microsoft.com/en-us/library/ed577840.aspx