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
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.
I have a WebPart custom control (Composite) in .Net, which gets created on page load to show a Chart using 'Dundas Charting Controls' (this is created by a user control inside the page). I get the properties for this control from the database.
I have another control, which is a Filter (outside webpart) and based on data of this filter control which the user selects and which I would get on postback after click of button, I have to show the filtered chart results. The problem is CreateChildControls() gets called before the postback data is available (which would be available only after the Page_Load event fires).
I'm unable to get this data in time to pass on the parameters for filtering the Chart Results.
The implementation os like this ...
Webparts
Page > User Control > Webparts > Composite Control/Chart
Filter
Page > User Control > Composite Control [I get this data on Postback]
It sounds like you are running into an event ordering issue. I always try to make my controles relatively dump - so they don't really know how they are being used.
Consider creating a method in your chart control to force an update of its data:
public void UpdateChart(-- arguments as needed --)
then create an event in your composit control (that has your filters) like
public event Eventhandler FiltersChanged;
Assign this to an event hander on parent page:
filterControl.FiltersChanged += new EventHandler(Filter_OnChange)
Then create an event handler that tells your chart control about the change
Filter_OnChange(Object sender, EventArgs e)
{
// get whatever data you need from your filter control
// tell the chart about the new data and have it reload/redraw
myChart.UpdateData( - filter options here -}
}
In doing so, you let the page direct the order of operations and do not rely on the order in which the child controls Load methods are called.
James - Thanks for your answer, but this does not seem to work in my scenario or rather I couldn't make it work, when I tried it. The controls seems to be doing too much and is getting data from every where, it has its own constructor implementation, Load() override etc so a single UpdateChart() function may not have done the trick in this case.
This is what I did, finally.
I fire an Ajax request with Filter Data and set the value in a Session Variable before page does a Postback, this way I get the data at all places/events, and pass on the same as parameter where required. I know it may seem weird way to implement this, but it saved additional Database calls (which in this case are many to create the controls again) even though it comes at the cost of an additional Server HTTP ajax request.
Let me know this implementation can have any negative impact.
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?