Here's a good one everybody. Probably another dumb programmer mistake, but I
can't find it yet.
The application I'm working on uses a Master Page which always displays a
banner and links at the top, a vertical menu (3rd party) on the left and a
footer.

A very simple content page consists of a centered table defined at static
width of 500px. It contains a number of HTML input textboxes, an asp:button
for submit, an asp:lisbox(1 row) and an HTML input Reset button. The purpose
is to allow the user to edit and update their own contact information. I use
a good bit of simple HTML as it renders faster and uses less server
resources.

Upon initial page-load the page gathers the user information from a SQL
Server 2005 table and displays it.
Upon postback to itself, the page the updates the SQL table, and re-selects
the data so that when the page again displays, the user can see the result
of his changes. All of that is working fine.

I have added some server-side data validation. If one of the fields does not
pass muster I assemble and display a javascript alert box, which pops up
just before the page refresh, thusly...

Response.Write("<script type=text/javascript>")
Response.Write("alert('View All must be either Y or N')")
Response.Write("</script>")

It works fine if I again Select the table data and plug the variables
associated with the input fields before allowing the page to re-display.
But I realized that re-initializing the data if the validation fails and no
Table update occurs, would put the page back to the initial state...and the
user must re-enter all the fields. Yes, I plan to implement client-side
validation, but server-side validation is also important.

So , in the case of a validation failure, I skipped the Select from the SQL
table and just used the data in the fields as passed in the postback, in
order to retain state (like in the classic ASP days). However, when I do
this the, page reload results in a form table that is 26 times the width of
the full-screen browser window! Yikes. My first thought is that there is
some data in the post-backed variables that is incredibly long, thereby
stretching the table width to enormous proportions.

I have spent 6 hours examining the data and cannot find any untrimmed string
data. It all looks correct.

So, has anybody seen such behavior before and is there another place to look
besides the data in the input text fields?

Thanks to all