Those of you that sat for my second session know that it was focused on how to effectively use JavaScript in the enterprise. Since the conference, I’ve come across a very promising library called Durandal http://durandaljs.com/ If you’re using JavaScript to build apps, I strongly recommend you take a look at this framework. 

You can find the slides and demo code in my SkyDrive folder here: http://sdrv.ms/YA1A8O

Michael McNett is McNuts about SharePoint.
He’s a fan of Fast Search and a Friend to refining.
Content types make him cry like he’s christened a son.
Extranets excite him and his eyes you’d see shining
If integrating InfoPath is the job to be done.
Populating profile properties is Mike’s thrill.
He loves publishing the perfect profile post.
His RoadMap is no ruse. If you need things done right,
It’s the best way to ensure that your timeline is tight.

BTW, you can find Mike’s through his blog,http://mmcnett.wordpress.com/, on LinkedIn or twitter (@CIO_Mike)

The conference will be at the Columbus Convention Center on March 21.  My coworkers did a great job on the web site and I’m pretty pumped about giving two afternoon development presentations. WooHoo!

• Unfortunately #1) This is a simple task, so if something goes wrong, you won’t find much help out there.
• Unfortunately #2) Something went wrong.

I found that  when I tried to republish my form, I received an InfoPath error dialog “The SOAP message cannot be parsed.”  In fact, I found that if I just opened and, making no changes, published the form, it would also fail.

Not useful. So I fired up Fiddler in hopes I would be able to get a little more information about the error.

You can see above that my client is actually not receiving an HTTP error. Instead I’m receiving an error page, and a quick look at the url for that page shows that the actual problem is a timeout (/_layouts/error.aspx?ErrorText=Request%20timed%20out)

Inspecting the payload shows that this is the branded SharePoint error page.from the error page shows that the actual problem is a timeout issue.

#HeadSmack: Only now as I’m writing this up does it dawn on me that because the above response is the standard error page, I probably could have dug into the HTML there and pulled out the correlation ID and then traced the issue into the logs for more information.

Normally, you’d go to the logs for something like this, but in this instance, I don’t have direct access to the logs and without a correlation ID getting any info back is difficult. Instead I go to Bing I do find a few references to how this timeout duration can be changed on the farm.  However, this form is already in place and I can’t even republish the same version.  It didn’t feel right that I should need to change farm settings to correct the issue.

As far as I know, none of the form’s xml gets stored in with the actual list item. Still there were 2499 items in the list now, which is way more than there were when this form was originally created.  If maybe the system took some action, be it validation or update, to each list item when the form was updated, a timeout would seem plausible.  On a hunch I decided to try reducing the number of items in the list.

Starting with the items with the oldest modified dates, I began deleting them 100 at a time. With the intent on recovering them from the recycle bin if all goes well.

About 1000 items into the process my error message changed, which felt promising.

Then at the magic number of 1199: Success! WTF??! Oh well, I’ll take it.

So I made all of my updates, and republished the form. I then went back into the recycle bin and restored all the deleted items.

All the items came back fine without so much as an altered modified date. (It’s 2013 now. Those dates are a year ago. I’ll admit the coincidence of the timing did cause me a split second of panic.)

I don’t know why it should matter how many items are in the list and this is a hacky workaround, but in a pinch or with a reluctant admin, this may be the hack you’re looking for.