Would appreciate any help on this :-) (Probably something like: read page xxx of the Documentation pdf file - doh!)

Scenario: On several different pages, I have an infragistics UltraWebGrid bound to an LLBLGenDataSource or LLBLGenDataSource2. Some pages with LivePersistence set to false, some with it set to true. In either condition I have the following problem:

Problem: I dont understand where I can/need to trap for ArgumentOutOfRangeException on the LLBLGenDataSource when in the "asp.net 2.0 data binding black box" on a postback hits an exception.

Simple Repro example: I have an UltraWebGrid bound to an LLBLGenDataSource which is configured to use SelfServicing CollectionClasses Collection. There is a column that is mapped to a varchar(80) field, I input 176 characters into the cell and click a Save button that does a postback. It seems when the UltraWebGrid communicates to the LLBLGenDataSource through the "asp.net 2.0 data binding black box thing" the following exception/ArgumentOutOfRangeException occurs for which I dont know what event I can implement in my C# .cs code behind page to catch this exception and show a user friendly error instead for: (*Note: I have tried to implement events on PerformSelect, PerformWork, Databinding, Disposed, and PerformGetDbCount on the LLBLGenDataSource , and none of these events seem to fire AFTER the ArgumentOutOfRangeException occurs. The page seems to stop processing and returns to the client browser. **Note: I also know I can put validators in on the grid, but this is a simple example that demonstrates throwing the ArgumentOutOfRangeException that I can learn how to implement proper error handling with the given configuration :-) )

System.ArgumentOutOfRangeException was unhandled by user code Message="The value specified will cause an overflow error in the database. Value length: 176. Column max. length: 80\r\nParameter name: ProgramTypeDesc" Source="SD.LLBLGen.Pro.ORMSupportClasses.NET20" ParamName="ProgramTypeDesc" StackTrace: at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase.ValidateValue(IEntityField fieldToValidate, Object value, Int32 fieldIndex) at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase.SetNewFieldValue(Int32 fieldIndex, Object value, Boolean checkForRefetch, Boolean fireChangeEvent) at SiteCentralData.SelfServicing.EntityClasses.ProgramTypeEntity.SetNewFieldValue(Int32 fieldIndex, Object value, Boolean checkForRefetch) in C:\WorkingFolder\Tony.Norton\MTGIProducts\SiteCentral.root\src\SCDataObjects\LLBLGenProv2.0\ SiteCentralData.SelfServicing\EntityClasses\ProgramTypeEntity.cs:line 583 at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase.SetNewFieldValue(String fieldName, Object value) at SD.LLBLGen.Pro.ORMSupportClasses.LLBLGenProDataSourceView.SetEntityValues(IDictionary values, IEntity entity) at SD.LLBLGen.Pro.ORMSupportClasses.LLBLGenProDataSourceView.ExecuteUpdate(IDictionary keys, IDictionary values, IDictionary oldValues) at System.Web.UI.DataSourceView.Update(IDictionary keys, IDictionary values, IDictionary oldValues, DataSourceViewOperationCallback callback)

Thanks, Tony

*Edited to make changes referencing appropriate LLBLGenDataSource type (SelfServicing rather than Adapter).

You should handle the events of the UltraWebGrid bound to an LLBLGenDataSource2. There should be something like..... xxx_ItemInserted Or xxx_ItemInserting ...etc

Ok, so the idea is that the grid communicates with the llblgendatasource upon a postback, and that during this communication phase, that it's the responsibility of the grid (control) to handle/track exceptions, which then the control should have an event tied to during or after this communication with its datasource that I then can check for System.ArgumentOutOfRangeExceptions.

I will look into this and postback my results.

Thanks for the help and quick response Walaa!

Note: I also apologize for a little screw-up I had in the first post, I was actually on a page with a SelfServicing LLBLGenDataSource not the Adapter LLBLGenDataSource2, for which the grid and datasource threw the exception.

Question for Franz / Walaa,

Is there a reason why the LLBLGenDataSources (Adapter and SelfServicing) do not support equivalent events as to the SQLDataSource and ObjectDataSource events for Deleted, Selected, Inserted, and Updated &/or Deleting, Selecting, Inserting, and Updating?

I ask this because it seems that the UltraWebGrid does not support equivelent events you would find on the GridView control, RowDeleting, RowUpdating, or RowCreated. Which means, your suggestion of handling events on something like xxx_ItemInserted Or xxx_ItemInserting doesn’t seem to be available with the Infragistics UltraWebGrid control.

Which it’s obvious that I need to go to Infragistics and ask them the same question. Doh!

As a side question: Are there two camps on how to deal with Exception Handling Management?

One camp where they say to put it on the datasource, the other that says put it at the controls? In my limited time doing ASP.NET 2.0 dev work, I personally haven’t come across any "Best practice" resource/documentation that covers Exception Handling Management related to what I still call the "asp.net 2.0 data binding black box thing" (which again to how I would describe the communication/execution of code on a postback between the control and datasource that I usually don't get to see in my dev debugging environment).

Thanks, Tony

Also note I have the same type of question on the Infragistics forums: [urldescription="Message on infragisticsforum"]http://news.infragistics.com/readmessage?id=%3C308971ec$17d88e50$1aae5a@news.infragistics.com%3E&group=infragistics.products.netadvantage.aspnet.webgrid[/url]

Trying to find the appropriate Exception Handling Management between these two 3rd party tools

Thanks, Tony

TonyN wrote:

Question for Franz / Walaa,

Is there a reason why the LLBLGenDataSources (Adapter and SelfServicing) do not support equivalent events as to the SQLDataSource and ObjectDataSource events for Deleted, Selected, Inserted, and Updated &/or Deleting, Selecting, Inserting, and Updating?

I ask this because it seems that the UltraWebGrid does not support equivelent events you would find on the GridView control, RowDeleting, RowUpdating, or RowCreated. Which means, your suggestion of handling events on something like xxx_ItemInserted Or xxx_ItemInserting doesn’t seem to be available with the Infragistics UltraWebGrid control.

Which it’s obvious that I need to go to Infragistics and ask them the same question. Doh!

The events aren't there as there's no use for them. If you want to intercept the actions, switch LivePersistence off by setting it to false and use the 3 events exposed by the llblgenpro datasourcecontrols and do your own fetching/persisting in a few lines of code. 'No use for them' as in: I couldn't come up with a single example in which situation these events could be used. This is also because llblgenpro uses other mechanisms for for example validation.

As a side question: Are there two camps on how to deal with Exception Handling Management?

One camp where they say to put it on the datasource, the other that says put it at the controls? In my limited time doing ASP.NET 2.0 dev work, I personally haven’t come across any "Best practice" resource/documentation that covers Exception Handling Management related to what I still call the "asp.net 2.0 data binding black box thing" (which again to how I would describe the communication/execution of code on a postback between the control and datasource that I usually don't get to see in my dev debugging environment).

Thanks, Tony

databinding is about giving away control over what's going on. You're no longer in control when what happens, the databinding goo is.

When an exception occurs, the databinding code often decides (in various controls this is the case) to simply stop with what it is doing. In your own code, you'd probably treat an exception as something exceptional and take care of it in a different way.

So it's hard to say what to do. With asp.net it's even more difficult than with winforms as in webforms you've to produce a valid piece of HTML otherwise it won't show up in the browser so an exception must not interrupt that process.

Frans wrote:

The events aren't there as there's no use for them. If you want to intercept the actions, switch LivePersistence off by setting it to false...

Ok, so I have an UltraWebGrid, Version=6.2.20062.34, configured to use an LLBLGenDataSource2 with LivePersistence set to false.

To quickly demonstrate how to throw an exception, I have the following set of events in a diagram: *Note, that even though I can put a validator on the grid, what I am really after is a way to handle/trap ANY/ALL exceptions thrown from the "databinding goo". Being similiar to how I could implement a solution with SQLDataSource, ObjectDataSource and ASP.NET native controls that are able to handle "databinding goo" exceptions.

http://www.twango.com/original.aspx?channelname=TonyN.public&media=TonyN.10001 permalink:

*Note that the numbered sequence in the jpg are the steps of F10 button clicks when I debug in my Visual Studio 2005 environment.

The suggestion of switching to LivePersistence off does not seem to help solve for this issue.

Outside of handling exceptions in this configuration, we would also like to implement the feature of catching an exception like this, and have the ability (data model and asp.net/C# code) to translate exceptions to friendly errors, with friendly errors being determined by power users of the asp.net apps we are building. So, when an exception, like the one in my example, occurs, the user can relate a friendly message like: "Unable to make update because you have exceeded the field length for the cell you are updating" and we can assign it to a general message label on the page on the way back out of a postback when that user or any other user encounter the exception in the future.

So I am at a point of wondering a few things: 1. Am I only stuck with javascript / asp.net validation to guard against ANY/ALL possible exceptions in the "databinding goo"? 2. Am I the only one tackling this issue? And is it a non-issue because I am not aware of other principles/practices, which allow this issue to be benign? 3. Do others, like Frans, his company or friends/collegues/customers at other companies solve for Exception Handling Management specifically for the "databinding goo" another way? If so, than is it that I have yet to learn what the "best practices" are for this situation in the ASP.NET 2.0 framework? And if this is the case, can anyone here point me in the right direction so I can solve for this?

I definetly appreciate your help and insight to get me to the point I can implement a stable application using these 3rd party tools.

I hope my questions, writing, and probably ignorance hasn't offended anyone

Im just trying to engage this as best as I can.

Thanks, Tony

Let me first say that our datasourcecontrols are written with the scarse documentation MS provided as well as the functionality of objectdatasource in mind. We didn't look at 3rd party controls how they want to behave with the datasourcecontrols, as that's not correctly designing OO code: you've to write a solid set of classes which have a sold interface (all controls work with the base class' DataSourceControl anyway, or at least should be), and always act the same. As there are a lot of controls out there, we test with the vanilla controls shipped with .NET. if these work, it works. If these break, our code needs fixing. If a 3rd party control breaks, and the vanilla control works, it's almost always a bug in the control vendor's code, history has learned that.

Added to that: infragistics has a bad trackrecord and with every control they release I expect it to fall apart sooner or later. I've stopped being polite with these people and with other control vendors who think they should do their own way of databinding: if their controls don't work, drop them and get another vendor's product.

What we also stopped doing is trying to do the support work for 3rd party control vendors. it's simply impossible to write workarounds for all the misbehaving control code out there. Databinding is broken as it is, and we've already a hard time writing code which works in 100% of the occasions with MS controls, left alone 3rd party controls which are written by people who think databinding works differently.

With datasourcecontrols, it's very simple though. The bound control calls ExecuteSelect, ExecuteDelete, ExecuteUpdate or ExecuteInsert on the datasourcecontrol to get things done, and passes information to these methods what has to be done. the datasourcecontrol then returns data or performs the action. That's it.

When LivePersistence is set to true, everything is done by the datasourcecontrol. When LivePersistence is set to false, the datasourcecontrol doesn't do anypersistence logic calling, it raises events and YOU have to perform these actions. ANY Exception occuring inside the event handlers will bubble upwards to the control, however it's hard to write catch clauses for that.

There's NO guideline nor documentation how this should be done: should there be an exception of a given type? I have NO idea, there's no documentation on this. THis thus means that every control for itself cooks up a different way to deal with this.

TonyN wrote:

Frans wrote:

The events aren't there as there's no use for them. If you want to intercept the actions, switch LivePersistence off by setting it to false...

Ok, so I have an UltraWebGrid, Version=6.2.20062.34, configured to use an LLBLGenDataSource2 with LivePersistence set to false.

To quickly demonstrate how to throw an exception, I have the following set of events in a diagram: *Note, that even though I can put a validator on the grid, what I am really after is a way to handle/trap ANY/ALL exceptions thrown from the "databinding goo". Being similiar to how I could implement a solution with SQLDataSource, ObjectDataSource and ASP.NET native controls that are able to handle "databinding goo" exceptions.

http://www.twango.com/original.aspx?channelname=TonyN.public&media=TonyN.10001 permalink:

*Note that the numbered sequence in the jpg are the steps of F10 button clicks when I debug in my Visual Studio 2005 environment.

The suggestion of switching to LivePersistence off does not seem to help solve for this issue.

I'm sorry, but it's all you have. In the event handlers you can perform the exception catching and based on the caught exceptions set variables in the page which you use in the page itself from then on.

But always remember: web != winforms. Web is request-response and you've ONE chance to get that response, and it has to be correctly formatted (the html). In winforms, it's a completely different ballgame, so you should write a webapplication as a webapplication: gather info, process info, get result, not as a winform application, as that's not going to work no matter how much javascript people are able to throw onto it.

So an exception in a code behind is likely to terminate the response if you're not careful.

Outside of handling exceptions in this configuration, we would also like to implement the feature of catching an exception like this, and have the ability (data model and asp.net/C# code) to translate exceptions to friendly errors, with friendly errors being determined by power users of the asp.net apps we are building. So, when an exception, like the one in my example, occurs, the user can relate a friendly message like: "Unable to make update because you have exceeded the field length for the cell you are updating" and we can assign it to a general message label on the page on the way back out of a postback when that user or any other user encounter the exception in the future.

So I am at a point of wondering a few things: 1. Am I only stuck with javascript / asp.net validation to guard against ANY/ALL possible exceptions in the "databinding goo"?

Yes.

the problem is that the # of entities to save can be more than one in some grids. (the datasourcecontrols are designed to handle this, .net gridview always returns just one though). So the datasourcecontrol gets 1 or more to process. If there are more, what's to report when some entity fails, say entity 4. ? Or better: how to report it? there's no way to do so. Remember: web is request response. So a response is being created when this code is executed.

the lowlevel approach used in the old days was - validate input - if valid, persist input into database using dal

you want to skip step 1, though you can do that only in validators set on the grid, which for example use the meta-data exposed by the datasourcecontrol at design time so fieldlengths are available and designed into the grid. I can't help it if infragistics doesn't use the proper designer interfaces to retrieve this info. I have to add to this that there was a bug in the datasourcecontrol a couple of weeks ago which blocked the fieldlength info from being propagated to the bound control at design time.

So check it at the client side, with the functionality in the grid. If the data is then still badly formatted, due to the fact that the person posts the data with a custom http post script (i.ow.: tries to hack his way into the page), the code will throw an exception and he won't get far.

Frans, Thanks for clarifying your position and some of the paths you had to take, as I can only appreciate the pain you must have endured in writing your datasource controls based on what MSFT didn't give you. My intention was not to bust your chops on the comparison of Microsofts controls versus your product. My intention was to explain/diagram as much as possible, with a quick set of repro steps, to have both of us on the same page. As well as provide enough keywords as to allow others to search on this topic if it helps them to understand what I am learning.

At the end of the day, using your product and reading your forum I believe: 1. You have created an excellent product. 2. Yourself, Walaa and support staff do the best that you can, which is really good, with what you have to work with from peoples postings, like mine! Not every developer / customer is the same.

Keep up the good work! Tony

*Note: I hear exactly what you are saying in regards to infragistics. It just gets back to an issue with companies like ours: Build vs. Buy in regards to the amount of time and dev hours we have (or dont have) to push our apps/tools out the door. Sherman Tank (Have a package of features that can support longevity across multiple projects, though might have some shortcomings) vs. Honda civic (Economic, lightweight and specialized to what we need this time around, but might not satisfy the next project)

Hmm, that probably was a bad analogy!

TonyN wrote:

Frans, Thanks for clarifying your position and some of the paths you had to take, as I can only appreciate the pain you must have endured in writing your datasource controls based on what MSFT didn't give you. My intention was not to bust your chops on the comparison of Microsofts controls versus your product. My intention was to explain/diagram as much as possible, with a quick set of repro steps, to have both of us on the same page. As well as provide enough keywords as to allow others to search on this topic if it helps them to understand what I am learning.

Oh I didn't interpret your post as critizism, sorry if I sounded that way. I wanted to give some background in which light you should see these datasource controls and how fragile the whole process of databinding really is.

At the end of the day, using your product and reading your forum I believe: 1. You have created an excellent product. 2. Yourself, Walaa and support staff do the best that you can, which is really good, with what you have to work with from peoples postings, like mine! Not every developer / customer is the same.

Keep up the good work! Tony

Thanks for the compliments!