'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 that
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:
Quote:
Originally Posted by
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:
Quote:
Originally Posted by
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 that
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:
>
Quote:
Originally Posted by
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?
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:
Quote:
Originally Posted by
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:
>
Quote:
Originally Posted by
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 that
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:
Quote:
Originally Posted by
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?
0 comments:
Post a Comment