views:

81

answers:

2
+1  A: 

Questions I would ask include:

  1. How are you maintaining state? Are you using in-proc sessions? I ask because the users are likely being bounced from one server to the next. Have you tried switching to cookie based sessions?

  2. Can you put a logger on the page load to save everything from the Request object. Specifically, all of the form fields submitted?

  3. What, exactly, is the error message?

EDIT
If some values are coming, then that is a strange situation. How are you decrypting the data? and, again, what is in the underlying Request object itself? How are you accessing the fields to determine they "aren't there"? At what point in the pipeline is the decryption occurring? Is it mangling the rest of the request object?

Chris Lively
4. why the CAPS;)
redsquare
1) because of the load balancer the state is handled through form and cookies<br>2) Interesting idea<br>3) no error message - just empty data
Dave
CAPS are coding style adopted when I learned HTML back in the 90s
Dave
@Dave Just so you know, caps aren't considered to be browser compliant anymore.
TheGeekYouNeed
Dave
+1  A: 

I had a similar problem that took a few days to figure out. I was porting an application from ColdFusion to .NET 3.5 and the page seemed to post back, but most of the request was lost.

The problem was with having a form element which wasn't marked with a runat="server" tag being nested within the form tag marked with a runat="server".

My resolution was simple: I removed the html-based form element and relied on the main form. Your issue sounds slightly different because you're dynamically building the form. From my research during that time, I learned that form elements shouldn't be nested and that only one per page can be server-side.

MSDN Magazine has an article with several options for displaying multiple forms on a single page: http://msdn.microsoft.com/en-us/magazine/cc164151.aspx#S4

However, if your generated forms are fairly simple as you've posted, you may consider generating the controls and using an asp:Button control's PostbackUrl property to set the page to which a postback should be submitted.

An example, taken from MSDN:

  <form id="form1" runat="server">

    <h3>Button.PostBackUrl Example</h3>

    Enter a value to post:
    <asp:textbox id="TextBox1" 
      runat="Server">
    </asp:textbox>

    <br /><br />

    <asp:button id="Button1" 
      text="Post back to this page"
      runat="Server">
    </asp:button>

    <br /><br />

    <asp:button id="Button2"
      text="Post value to another page" 
      postbackurl="Button.PostBackUrlPage2cs.aspx" 
      runat="Server">
    </asp:button>

  </form>

Notice how clicking the first button posts back to the current page, and clicking the second button posts back to Button.PostBackUrlPage2cs.aspx and contains the value entered in the textbox in the Request object.

Jim Schubert
must check - Excellent catch - I thought I took all of them out.
Dave
found a few - removed them - will see Monday - thanks
Dave
Hopefully that's all it was. I didn't even know this was a limitation in ASP.NET, which is why it took me so long to find a solution.
Jim Schubert
logger shows that some people are still not getting through, but I mark that down to not following the directions.
Dave