.net_2.0

Part 4 - Building a Submission Form that Saves In Progress Drafts (MSFT AJAX)

Today's entry will outline some of the bugs with previous code.  For some reason code that works absolutely fine in my normal project solutions did not work with the Web Application Project solution the AjaxToolkit uses.  Thus - I glad to report we have the underlying cause for the Sys.ParameterCountException: Parameter count mismatch error that Part 3 of the series left us with.

Specifically, the issue had to do with these lines of code:

        cmd.Parameters.Add(PARM_NAME.Value = Title);
        cmd.Parameters.Add(PARM_CATEGORY.Value = Category);
        cmd.Parameters.Add(PARM_SUMMARY.Value = Summary);
        cmd.Parameters.Add(PARM_KEYWORDS.Value = Keywords);
        cmd.Parameters.Add(PARM_ARTICLETEXT.Value = Article);
        cmd.Parameters.Add(PARM_USERNAME.Value = HttpContext.Current.Request.LogonUserIdentity);
        cmd.Parameters.Add(PARM_SESSIONID.Value = HttpContext.Current.Session.SessionID);
        cmd.Parameters.Add(PARM_DATEUPDATE.Value = DateTime.UtcNow.ToString());

How did we find the error?  Well anytime that your create a web service, you can actually view the WSDL (which basically describes all the methods and XML formatting required for them to work) from the browser as seen in this screenshot: (For some reason the new upgrade to CS 2.1 has broken the ability to embed images so clicking on the link will bring it up in a new window)...

 So, I attached the Debugger and set the break point on the web service method.  This was the resulting error:

System.InvalidCastException: The SqlParameterCollection only accepts non-null SqlParameter type objects, not String objects.
   at System.Data.SqlClient.SqlParameterCollection.ValidateType(Object value)
   at System.Data.SqlClient.SqlParameterCollection.Add(Object value)
   at SubmissionService.SaveBackGroundBackup(String Title, String Category, String Summary, String Keywords, String Article) in d:\Atlas\Beta\AtlasControlToolkit\Release\SampleWebSite\App_Code\SubmissionService.cs:line 72

Which puzzled me.  As stated, I have another project but using the default project mode of Visual Studio - so a search on the net led me to the solution posted by Peter Bromberg at eggheadcafe.com.

So the code has been changed to this:

PARM_NAME.Value = Title;
            PARM_CATEGORY.Value = Category;
            PARM_SUMMARY.Value = Summary;
            PARM_KEYWORDS.Value = Keywords;
            PARM_ARTICLETEXT.Value = Article;
            PARM_USERNAME.Value = HttpContext.Current.User.Identity.Name.ToString();


            PARM_SESSIONID.Value = HttpContext.Current.Session.SessionID.ToString();
            PARM_DATEUPDATE.Value = DateTime.UtcNow;

            cmd.Parameters.Add(PARM_NAME);
            cmd.Parameters.Add(PARM_CATEGORY);
            cmd.Parameters.Add(PARM_SUMMARY);
            cmd.Parameters.Add(PARM_KEYWORDS);
            cmd.Parameters.Add(PARM_ARTICLETEXT);
            cmd.Parameters.Add(PARM_USERNAME);
            cmd.Parameters.Add(PARM_SESSIONID);
            cmd.Parameters.Add(PARM_DATEUPDATE);

Upon which we discover that: No session info is actually recreated.  Which means we shall have pass both the session id and the user name along with the rest of the request.  Now I realize what some of the conversations about the wanting page methods not to be static anymore.  And perhaps at some point in time we may discover that we need to implement that type of access.

 However, at this point I want to digress from the code for a a bit as 1. its a Friday night and 2. I discovered a very bizarre issue this afternoon in regards to the effects of constant ScriptResource.axd errors have at least on a development system.

I had left IE 6 open on the sample page.  As noted every time the system polled -  an error ensued.  Around 3 AM this morning, IE crashed and took with it IIS, and as a friendly gesture SQL Management Studio, all open Visual Studio Projects, and a few other apps.  Although my Remote Desktop Connection, command window, and Firefox were still left running.

 The Application Event Log reported this error:

 
Faulting application inetinfo.exe, version 5.1.2600.2180, faulting module webengine.dll, version 2.0.50727.210, fault address 0x0000a946.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

We all know that one of the reasons that the recommended best practice for Ajax is to include a dispose method. However, it was my understanding that if including javascript inline on the page through <script> tags, that the objects would automatically be disposed.   Memory leaks will occur javascript (especially with IE), but the concern is why IIS would crash in this scenario.  The browser - I can understand, but not IIS even if its just on XP. 

 I am going to let the scenario continue... and in Part 5 we shall delve into a actual working system (or so I hope)...

Stay tuned... 

NOTE: The series will be on hold until actual formal documentation for Microsoft's Ajax is released.   Unfortunately while trying to troubleshoot the issues with the Jscript - the documentation all refers mainly to Atlas (which allows for embedding script.js files in the <Head><.Head> tags. As a result - this article series - would be nothing but part after part of 'how to troubleshoot" when in fact one can't exactly program to a technology if you do not understand the technology - which makes troubleshooting a very vain attempt at best....