On 'crash-proofing' ASP.Net 2.0 code

This is related to an earlier post of mine. In a general sense, how does on
e
'crash-proof' 2.0 webpages, especially when dealing with legacy databases?
To be more specific, Visual Studio 2005 and ASP seem to be extremely
unforgiving of bad or null data, especially datetime fields and bad values
that are intended to set dropdown list indices.
Short of manually writing binding code, is there any way to deal with
problems like this?It *sounds* like you are talking about "bad data" due to invalid user inputs
.
ASP.NET sports a nice set of Validation Controls (including a Custom one tha
t
you can write your own code in) to ensure that users cannot enter bad data.
--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com
"B. Chernick" wrote:

> This is related to an earlier post of mine. In a general sense, how does
one
> 'crash-proof' 2.0 webpages, especially when dealing with legacy databases?
> To be more specific, Visual Studio 2005 and ASP seem to be extremely
> unforgiving of bad or null data, especially datetime fields and bad values
> that are intended to set dropdown list indices.
> Short of manually writing binding code, is there any way to deal with
> problems like this?
Actually no, user input I can deal with.
What I was thinking of was massive legacy databases full of questionable or
non-existent data integrity (and either too big to cleanup overnight or
politically off-limits), as well as wannabe DBAs going into tables directly
and modifying data, just to make my life even more interesting than it
already is.
It just seems vastly easier to handle this sort of thing in Winforms.
"Peter Bromberg [C# MVP]" wrote:
> It *sounds* like you are talking about "bad data" due to invalid user inpu
ts.
> ASP.NET sports a nice set of Validation Controls (including a Custom one t
hat
> you can write your own code in) to ensure that users cannot enter bad data
.
> --Peter
> "Inside every large program, there is a small program trying to get out."
> http://www.eggheadcafe.com
> http://petesbloggerama.blogspot.com
> http://www.blogmetafinder.com
>
> "B. Chernick" wrote:
>
The issues you just described are just as susceptible to Windows Forms apps
as they are to ASP.NET apps.
--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com
"B. Chernick" wrote:
> Actually no, user input I can deal with.
> What I was thinking of was massive legacy databases full of questionable o
r
> non-existent data integrity (and either too big to cleanup overnight or
> politically off-limits), as well as wannabe DBAs going into tables directl
y
> and modifying data, just to make my life even more interesting than it
> already is.
> It just seems vastly easier to handle this sort of thing in Winforms.
> "Peter Bromberg [C# MVP]" wrote:
>