On Dec 26, 1:43*pm, "Scott Roberts" <srobe...@no.spam.here-webworks-
software.comwrote:
Quote:
Quote:
Quote:
You have to catch the exception when the SelectedIndex or SelectedValue
of
the DDL is set. I'm not sure how to do this if you're using data-bound
controls (we don't use databound controls). What is the default value of
the
DDL for new items? I'd set it to that.
>
Quote:
We are extremely dependent on data binding. We have had bad
experiences with manual binding and tend to avoid it.
>
I've had exactly the opposite experience! Regardless......
>
Quote:
The DDL for
ASP .NET lacks many useful features, but that is a limitation from
HTML. For instance, you cannot add a new value to the list directly.
Instead, you have to modify the data source and rebind.
>
I believe that you can add "static" items then set the
"AppendDataBoundItems" property to True. Careful though, the DDL will not
automatically clear items when you rebind if you do this. You'll need to
handle situations where you re-bind DDLs carefully.
The only static item we could make would be a blank or "null" field.
We have many instances where "null" is not allowed, so that eliminates
that option. Currently, the application just explodes and we are sent
a message about where to find the bad data. The real problem is that
ASP .NET will attempt to validate each record returned by an
ObjectDataSource. So, if we have a FormView with a validated
DropDownList in it, we may get an error even if the current record is
fine. Somewhere in the results there is a bad record (and there could
be hundreds of records). We can only conclude that the bad record
belongs to a parent record, but not know the pin-point location. We
some times have to search carefully for the record that is in error -
it would be nice to get the bad record directly.
Perhaps I should simply search through my records and remove bad
records prior to releasing them to the interface. Then for each bad
record I can send an email to our DBAs. At least this way our users
don't experience bad data. I could indicate to them that some records
have been excluded and they have to contact the DBA to retrieve them.
Quote:
>
Quote:
The
SelectedIndexChanged event is "too late" since it takes place after
binding is completed (or after the error has already occurred). My
idea is to have a check occur when the business object with the
selected value is first queried. It would do the check first - if it
fails it could redirect the user to a screen where they can chose a
meaningful value. However, the details seem too complicated to do
generically.
>
Indeed. If you have a business object then all validation should occur there
anyway. Obviously DB constraints would be best, if possible. If anyone says
"But that will break application XYZ!" you can simply respond "Application
XYZ is already broken, it's just not generating exceptions when it breaks!".
:)
DB constraints here are rare and far between. Our databases are
ancient and lack some basics like foreign key constraints. We could
add them anytime, but for some reason we don't. I would hate to step
on someone's toes. :-\
Thanks, you got my wheels turning,
Travis